System and method for validation of distributed data storage systems

ABSTRACT

Provided herein is a risk framework tool for a distributed ledger-based computing system (i.e., blockchain) that can present a common risk framework to a user that can then allow for the user to determine what risks are important for it to manage. The risk framework can then take those specified risks and convert them in to a plurality of tests that can be used to validate the organization&#39;s blockchain system. In one or more examples, the risk framework can provide a graphical user interface to user that allows them specify the risks they wish to manage within the blockchain computing system, and based on the user&#39;s inputs, can determine one or more continuous real-time validation tests to be performed on the blockchain computing system so as to characterize the risk specified by user using the risk framework.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application which claims the benefit of U.S. Provisional Patent Application Ser. No. 62/579,093, filed Oct. 30, 2017, and U.S. Provisional Patent Application Ser. No. 62/579,095, filed Oct. 30, 2017, each of which are incorporated herein by reference in their entirety and for all purposes.

FIELD OF THE DISCLOSURE

The present disclosure relates generally to validation of distributed data storage systems, such as, for example, blockchain-based data storage systems.

BACKGROUND OF THE DISCLOSURE

A distributed data storage (which may be referred to as a distributed database) system may include data storage devices that are not connected to a common processing unit, but are in different computing systems located at the same physical location or dispersed across one or more networks of interconnected computing systems at different physical locations. The data storage devices may communicate with each other via one or more wired or wireless communication networks. Typically, each of the data storage devices includes a copy of the stored data. Storing copies of the data in different data storage devices may eliminate a single point-of-failure and may induce both higher availability and increased reliability of the stored data.

Blockchain technology may be used to implement a distributed data storage system. In the blockchain technology, a system of networked nodes, e.g., computers or servers, each store a copy of the entire distributed data storage system. The blockchain-based distributed data storage system is often referred to as a blockchain. Whenever a group of data records is to be added to the distributed database, i.e., blockchain, each node may independently verify the group of data records in a batch process known as generating a block (also referred to as a data block). In the batch process, a node verifies the group of data records based on its copy of the blockchain storing previously verified data records. A node that generates the block may transmit the generated block to every other node in the system. In current implementations, only after the block has been verified by each node in the system may each node add the block to its copy of the blockchain. As each of the nodes independently verifies the block, blockchain technology may reduce the risk of a single point-of-attack or a single point-of-failure. Further, since a copy of the blockchain is maintained at each node, the data can be stored in a redundant manner.

A blockchain is a record of data activities. These data activities can be transactions in a distributed ledger, and/or any movement of money, goods, and/or secured or unsecured data involved, for example, in a purchase at a supermarket, in the creation and storage of a user's digital identification, in the assignment of a government ID number, in energy data exchange in the energy industry, in an e-voting service, or in the recording, tracking, and transferring of deeds and contractual agreements.

FIG. 1 illustrates a blockchain process flow in accordance with examples of the disclosure. The blockchain process flow 100 can begin at step 102, wherein a user/party can request to implement a transaction in the blockchain. Examples of transactions can be storing data such as a record to a distributed ledger. Once the request has been made at step 104, the transaction can be broadcast to other computers (known as nodes) in the network. At step 106, the network of nodes can then validate the transaction using a mutually a priori agreed upon algorithm. Once each node in the network of nodes validates the transaction, the process can move to step 108, wherein the verified transaction can be combined with other transactions (described in detail below) to create a new block of data for the ledger. Once the verified transaction has been combined, the process can move to step 110 wherein the new block can be added to the network's block chain. The new block can be added in such a way as to make it permanent and unalterable (i.e., through the use of cryptography). Once the new block has been added the process can move to step 112 wherein the transaction is completed.

As shown in FIG. 1, a blockchain needs to do two things: gather and order data into blocks, and then chain them together securely using cryptography. A blockchain is a decentralized ledger of all transactions in a network. Using blockchain technology, participants in the network can confirm transactions without the need for a trusted third-party intermediary.

FIG. 2 illustrates the process of generating a data block in a blockchain in accordance with examples of the disclosure. In the process 200, a piece of digital content (i.e., a new transaction represented in binary) can be received. Once received, the process can move to step 204 wherein a hash function is applied to the received transaction, so as to combine it with data from a pre-existing block in the blockchain. The output of the hash function can produce a fixed and smaller-in-length unique digital output. Hash algorithms can carefully designed to flow one-way making it impossible to determine the original digital content from the output once the hash algorithm is applied. Every new block in the blockchain may be linked with the hash function of the previous block to create a chain. At step 206, once the has function has been applied, an output can be generated. The output of the hash function can be a part of the data that is used in the creation of blocks, and these blocks can then cryptographically chained together at step 208. This process of creating blocks allows the blockchain system to prove that a file existed in a particular format at a given time without having to reveal the data in the file.

One of the benefits of blockchain is that every participant in the network has simultaneous access to a view of the information, thus allowing almost real-time data availability and transparency that can eliminate the need for reconciliation. Also, the integrity and security of the information on the blockchain are ensured with cryptographic functions that can prevent unwanted intrusion on the network from non-authenticated participants. In blockchain technology, verification can be achieved by participants confirming changes with one another, thus replacing the need for a third party to authorize transactions and providing a facility for peers in the network to validate updated information, thereby ensuring the validity and integrity of the data on the blockchain. Another benefit of blockchain includes the ability to run additional business logic; this means that agreement on the expected behavior of financial instruments can be embedded in the blockchain, which can facilitate the ability to design and implement shared workflow and enhance automation. Also, the ability to issue a digital currency or a digital asset designed to work as a medium of exchange using cryptography to secure the transactions and to control the creation of additional units facilitates the ability to create and move assets without a trusted third party in the blockchain.

SUMMARY OF THE DISCLOSURE

Blockchain presents a challenge to the traditional validation (also referred to as audit) approach, given there's no practical way to use point-in-time forensic analysis—the standard validation tool. Attempting to conduct a point-in-time forensic retrospective analysis can be ineffective and wildly inefficient. The conventional approach to auditing can negate one of the benefits of implementing blockchain in the first place: the promise of increased administrative efficiency. Also, the traditional validation approach can require the entire blockchain hash function to be reversed to obtain transparency of the digital content without breaking the chain or sequential order of the blocks. Such approach could cause significant technical complexities, challenges, and inefficiencies in the validation of a blockchain-based data storage system.

Increases in the volume of data activities and rapidly evolving complex technologies are creating a critical need for business, technology, and compliance functions to be prepared, adaptive, and agile to emerging challenges. Due to the increase in data activities, current validation methodologies that are manual, sample-based, and point-in-time do not provide the needed level of confidence. Validation methodologies need to shift from a manual to an automated and continuous approach to address a significant increase in data activities and emerging, complex new technologies. Current audit methodologies cannot provide the necessary assurance in areas where a blockchain is used.

Accordingly, there is a need for systems and methods to replace the conventional validation approach with a real-time validating process to build confidence and assurance in the blockchain technology. The concept behind real-time validating is to inspect data activities closer and closer to the point of occurrence. Real-time validating eliminates the concept of sampling in the conventional validating process. The purpose of sampling is to perform backwards-looking assessments of segments of populations to draw conclusions about the rest of the population. The embodiments described herein provide blockchain assurance-related baselines that eliminate the need for sampling in blockchain validating.

The type of validation and auditing required for a given a distributed ledger-based system such as blockchain can be user specific. No two organizations may need the same validation regime to audit its blockchain system. Often times, various risks and concerns may be important in one context, but not as critical in others. Therefore, there is a need to specify the types of tests that will be used based on a specific user/organization's risk priorities. The present disclosure thus provides a common risk framework that can allow for a user to conveniently determine what risks are important for it to manage. The risk framework can then take those specified risks and convert them in to a plurality of tests that can be used to validate the organization's blockchain system. The risk framework can thus be used to customize a software tool that can then be used to perform real-time validation of an organizations blockchain computing infrastructure and system.

In some embodiments, a validation tool/system for any given blockchain use case may include tools for monitoring and validating of data activities (also referred as transactions) in one or more data blocks of the blockchain, risk evaluation of the data activities, business and technical risk and reporting assessments, and software that enables transaction level assurance for operational processes running on any given blockchain use case. The continuous assurance, compliance, monitoring, and validating methodology may be a combination of services and software intended to provide transparency in meeting the assurance and compliance needs of stakeholders. In some embodiments, the continuous assurance, compliance, monitoring, and validating of blockchains may be based on an acceptance criteria. In some embodiments, the acceptance criteria may include evaluating the current state of a blockchain use case against different risk categories (e.g., six or more different risk categories) and across sub-categories (e.g., 100 or more different sub-categories) in order to address assurance and compliance needs of stakeholders. This evaluation may be performed by a risk evaluation system that is industry, use case and Blockchain platform agnostic.

In some embodiments, a method for validating a blockchain-based data storage system is provided. The method comprising: conducting a risk analysis of using the blockchain-based data storage system in a specified environment; generating a risk profile of one or more data activities in a data block of the blockchain-based data storage system based on the risk analysis of using the blockchain-based data storage system in the specified environment; determining a number of times a validity test is to be performed on the one or more data activities in the data block to achieve a predetermined level of assurance, wherein the validity test tests compliance of the one or more data activities with an operating protocol of the blockchain-based data storage system; performing the validity test on the one or more data activities; and generating one or more validity test reports based on output of the validity test.

In some embodiments of the method, further comprising: displaying a user interface for selecting one or more test parameters of the validity test for testing compliance of the one or more data activities with the operating protocol of the blockchain-based data storage system; receiving from a user using the user interface one or more selections of the one or more validity test parameters based on the risk profile; and configuring the validity test based on the selection of the one or more validity test parameters.

In some embodiments of the method, the conducting the risk analysis comprises determining one or more risk categories of one or more risks involved in using the blockchain-based data storage system in a specified environment

In some embodiments of the method, the validity test is selected based on the risk categories.

In some embodiments of the method, the one or more risk categories are selected from a group consisting of government and oversight, cyber security, infrastructure layer, architecture layer, operational layer, and transaction layer.

In some embodiments of the method, the one or more data activities comprise storing one or more data in the data block.

In some embodiments of the method, the performing the validity test comprises performing the validity test continuously on the stored one or more data.

In some embodiments of the method, the generating the one or more validity test reports comprises: receiving from the user using the user interface a selection of one or more time periods within the one or more validity test; analyzing the output of the validity test during the one or more time periods; and generating the one or more validity test reports at end of each of the one or more time periods.

In some embodiments of the method, the performing the validity test comprises displaying, using the user interface, the output of the validity test; and wherein, in response to the output indicating that the one or more data activities failed the validity test, receiving from the user using the user interface a selection of whether the one or more data activities are exceptions to the operating protocol of the blockchain-based data storage system.

In some embodiments, a system comprising one or more processors and a memory comprising one or more programs, which when executed by the one or more processors, cause the one or more processors to: conduct a risk analysis of using the blockchain-based data storage system in a specified environment; generate a risk profile of one or more data activities in a data block of the blockchain-based data storage system based on the risk analysis of using the blockchain-based data storage system in the specified environment; determine a number of times a validity test is to be performed on the one or more data activities in the data block to achieve a predetermined level of assurance, wherein the validity test tests compliance of the one or more data activities with an operating protocol of the blockchain-based data storage system; perform the validity test on the one or more data activities; and generate one or more validity test reports based on output of the validity test.

In some embodiments of the system, the one or more processors are further caused to: display a user interface for selecting one or more test parameters of the validity test for testing compliance of the one or more data activities with the operating protocol of the blockchain-based data storage system; receive from a user using the user interface one or more selections of the one or more validity test parameters based on the risk profile; and configure the validity test based on the selection of the one or more validity test parameters.

In some embodiments of the system, the one or more processors are caused to determine one or more risk categories of one or more risks involved in using the blockchain-based data storage system in a specified environment

In some embodiments of the system, the validity test is selected based on the risk categories.

In some embodiments of the system, the one or more risk categories are selected from a group consisting of government and oversight, cyber security, infrastructure layer, architecture layer, operational layer, and transaction layer.

In some embodiments of the system, the one or more data activities comprises storing one or more data in the data block.

In some embodiments of the system, the validity test is performed continuously on the stored one or more data.

In some embodiments of the system, the one or more processors are caused to: receive from the user using the user interface a selection of one or more time periods within the one or more validity test; analyze the output of the one or more validity tests during the one or more time periods; and generate the one or more validity test reports at end of each of the one or more time periods.

In some embodiments of the system, the one or more processors are caused to display, using the user interface, the output of the validity test; and wherein, in response to the output indicating that the one or more data activities failed the validity test, the one or more processors are caused to receive from the user using the user interface a selection of whether the one or more data activities are exceptions to the operating protocol of the blockchain-based data storage system.

In some embodiments, a non-transitory computer-readable storage medium storing one or more programs for validating a blockchain-based data storage system, the one or more programs configured to be executed by one or more processors and including instructions to: conduct a risk analysis of using the blockchain-based data storage system in a specified environment; generate a risk profile of one or more data activities in a data block of the blockchain-based data storage system based on the risk analysis of using the blockchain-based data storage system in the specified environment; determine a number of times a validity test is to be performed on the one or more data activities in the data block to achieve a predetermined level of assurance, wherein the validity test tests compliance of the one or more data activities with an operating protocol of the blockchain-based data storage system; perform the validity test on the one or more data activities; and generate one or more validity test reports based on output of the validity test.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates a blockchain process flow in accordance with some embodiments.

FIG. 2 illustrates generation of a data block in a blockchain in accordance with some embodiments.

FIG. 3 illustrates shift in validating and control processes in distributed data storage systems in accordance with some embodiments.

FIG. 4 illustrates steps of a validation method for validating data activities in a data block of a blockchain data storage system in accordance with some embodiments.

FIG. 5A illustrates a correspondence of the risk framework testing procedures to a technology stack of a blockchain system according to examples of the disclosure.

FIG. 5B illustrates sub-categories corresponding to each risk framework category according to examples of the disclosure.

FIG. 6 illustrates an exemplary process for generating blockchain test procedures according to examples of the disclosure.

FIG. 7 illustrates an example of a computing device in according to examples of the disclosure.

Illustrative embodiments will now be described with reference to the accompanying drawings. In the drawings, like reference numerals generally indicate identical, functionally similar, and/or structurally similar elements.

DETAILED DESCRIPTION

Embodiments of the present disclosure may be implemented in hardware, firmware, software, or any combination thereof. Embodiments of the present disclosure may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by one or more processors. A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, a machine-readable medium may include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices, and others. Further, firmware, software, routines, instructions may be described herein as performing certain actions. However, it should be appreciated that such descriptions are merely for convenience and that such actions in fact result from computing devices, processors, controllers, or other devices executing the firmware, software, routines, instructions, etc.

The embodiments described herein may be implemented within a local computer system. The computer system may be implemented in the contexts of the likes of computing systems, networks, servers, or combinations thereof. The computer system includes one or more processors and main memory. Main memory may store, in part, instructions and data for execution by processors. Main memory stores the executable code when in operation, in this example. The computer system may further include a mass data storage, a portable storage device, output devices, user input devices, a graphics display system, and/or peripheral devices.

The components of the computer system may be connected to a communication infrastructure (e.g., a bus or network). Processors and main memory may be connected via a local microprocessor bus, and the mass data storage, peripheral device(s), portable storage device, and graphics display system may be connected via one or more input/output (I/O) buses.

Mass data storage, which can be implemented with a magnetic disk drive, solid state drive, or an optical disk drive, is a non-volatile storage device for storing data and instructions for use by processor. Mass data storage may store the system software for implementing embodiments of the present disclosure for purposes of loading that software into main memory.

Portable storage device may operate in conjunction with a portable non-volatile storage medium, such as a flash drive, floppy disk, compact disk, digital video disc, or Universal Serial Bus (USB) storage device, to input and output data and code to and from the computer system. The system software for implementing embodiments of the present disclosure may be stored on such a portable medium and input to the computer system via the portable storage device.

User input devices can provide a portion of a user interface. User input devices may include one or more microphones, an alphanumeric keypad, such as a keyboard, for inputting alphanumeric and other information, or a pointing device, such as a mouse, a trackball, stylus, or cursor direction keys. User input devices can also include a touchscreen. Suitable output devices include speakers, printers, network interfaces, and monitors.

Graphics display system may include a liquid crystal display (LCD) or other suitable display device. Graphics display system may be configurable to receive textual and graphical information and processes the information for output to the display device.

Peripheral devices may include any type of computer support device that adds additional functionality to the computer system.

The components provided in the computer system are those typically found in computer systems that may be suitable for use with embodiments of the present disclosure and are intended to represent a broad category of such computer components that are well known in the art. Thus, the computer system can be a personal computer (PC), hand held computer system, telephone, mobile computer system, workstation, tablet, phablet, mobile phone, server, minicomputer, mainframe computer, wearable, or any other computer system. The computer may also include different bus configurations, networked platforms, multi-processor platforms, and the like. Various operating systems may be used including UNIX, LINUX, WINDOWS, MAC OS, PALM OS, QNX ANDROID, IOS, CHROME, TIZEN, and other suitable operating systems.

The processing for various embodiments may be implemented in software that is cloud-based. In some embodiments, the computer system described above may be implemented as a cloud-based computing environment, such as a virtual machine operating within a computing cloud. In other embodiments, the computer system may itself include a cloud-based computing environment, where the functionalities of the computer system are executed in a distributed fashion. Thus, the computer system, when configured as a computing cloud, may include pluralities of computing devices in various forms.

The cloud may be formed, for example, by a network of web servers that comprise a plurality of computing devices, such as the computer system, with each server (or at least a plurality thereof) providing processor and/or storage resources. These servers may manage workloads provided by multiple users (e.g., cloud resource customers or other users). Typically, each user places workload demands upon the cloud that vary in real-time, sometimes dramatically. The nature and extent of these variations typically depends on the type of business associated with the user.

Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be coupled with the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the present invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

While various embodiments have been described below, it should be understood that they have been presented by way of example only, and not limitation. The descriptions are not intended to limit the scope of the invention to the particular forms set forth herein. Thus, the breadth and scope of a preferred embodiment should not be limited by any of the exemplary embodiments described herein. It should be understood that the description is illustrative and not restrictive. To the contrary, the present descriptions are intended to cover such alternatives, modifications, and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims and otherwise appreciated by one of ordinary skill in the art.

Blockchain validation tool/system (may be referred as Blockchain Continuous Assurance, Compliance, Monitoring and Validating Solution or Blockchain Continuous Validating Solution) can include a Continuous Assurance, Compliance, Monitoring and Validating Methodology (may be referred as continuous validating methodology), Continuous Assurance, Compliance, Monitoring and Validating Criteria (may be referred as blockchain validating criteria or acceptance criteria), blockchain risk evaluation system (may be referred as blockchain risk framework), business and technical risk and reporting assessments, and software that enables transaction level assurance for any given Blockchain use case. The validation system can include a combination of services and software designed for practitioners to provide transparency in meeting the assurance and compliance needs of users of blockchain-based data storage systems.

FIG. 3 illustrates an exemplary process for deploying a distributed ledger validation tool according to examples of the disclosure. In the example of FIG. 3, the process 300 can begin at step 302 wherein the customer's (who will be using the validation system) blockchain use-case is analyzed. The use-case analysis performed at step 302 can include as an example, determining the type of blockchain that is being used by the customer, analyzing how the customer is using the block chain to effect transactions and what solutions the blockchain is meant to deliver to the customer.

Once a use-case analysis is completed at step 302, the process can move to step 304, wherein a risk framework analysis is applied to the customer blockchain. A risk framework is a tool that can be used by stakeholders or auditors to assess and define the assurance and compliance needs of a particular blockchain use-case. The framework can allow the user to step through a series of categories of risks (i.e., risks to an organization engendered by their use of blockchain) to determine what risks they wish to audit for, and to determine the extent to which those risks would harm the organization. The risk framework described above can be industry, use-case, and blockchain technology agnostic so that practitioners across all industries and sectors can use to address the risk assurance and compliance needs independent of the Blockchain technology variant and use case.

Practitioners can use the risk framework as a standard approach and framework to evaluate the current state of a Blockchain use case which can be inclusive of upstream and downstream (on-Blockchain and off-Blockchain) processes, technologies, and underlying data elements (people, processes, technologies) against 6 different risk categories, applicable domains, and 100+ sub-risk categories in order to address assurance and compliance needs (risks, control objectives, controls, testing objectives and procedures, and reporting parameters) of the following stakeholders simultaneously or exclusively. The risk categories, domains and sub-risk categories can be used exclusively or mutually exclusively to determine targeted and/or upstream and downstream impacts. These parameters can be used to customize and personalize an assurance or auditing software/tool to achieve required level of assurance and compliance as by-product of processed transactions.

In one or more examples, the risk framework can include such categories as: governance and oversight of the blockchain, cybersecurity issues with the blockchain, infrastructure risks, blockchain architecture risks, operational risks, and transactional risks. As part of using the risk framework, a user can (via user interface) go over each risk category and the sub-categories within each risk category and indicate which risks are pertinent to their organization (or that they wish to be analyzed), and also indicate the degree and scope of those risks using the risk framework.

Once a user has engaged the risk framework at step 304 to identify the risks they want analyzed during an audit, the process can move to step 306 wherein the user-preferences supplied to the risk framework can be converted in to one or more testing procedures to be performed during the real-time compliance testing of the customer's blockchain. As will be described in further detail below, the testing procedures can then be used by the validation/auditing software to in real-time audit the blockchain.

Once the results from the risk framework are converted to testing procedures at step 306, the process can move to step 308, wherein the real-time auditing tool is customized using the results gleaned from the risk framework. In one or more examples, customizing the auditing tool can include setting up one or more testing procedures that the tool will engage in during its operation, and also setting up the formatting of the reports that the tool will ultimately produce for review by the customer (described in further detail below).

Finally, once the tool has been customized per based on the assessment of the use-case established at step 302 and the application of the risk framework at step 304, the process can move to step 310 wherein the tool is deployed in the customer environment. As will be described in further detail below, deploying the tool can refer to the creation of a validation node that becomes part of the customer blockchain environment. The validation node can be a read only node that includes the software to run the test procedures discussed with respect to step 306 on blockchain transactions as they occur in real time in the customer environment.

In one or more embodiments, the validation system created by the process described with respect to FIG. 3, may utilize a permanent planning file that can contain the details and results of the risk framework application, that can then be used at step 306 to convert the risk framework results into testing procedures. In other embodiments, the permanent planning file can instead be directly created by a user without the need to engage in the risk framework analysis above.

In some embodiments, the above set of activities of the validating methodology may be executed systematically (e.g., via software, hardware, or a combination thereof) with manual input by the auditor or compliance practitioner. In one or more examples, the validating methodology described above with respect to steps 302 may be divided into three phases (e.g., planning, fieldwork, and reporting sprints). The three phases are described below.

Planning Phase: In some embodiments, steps 302, 304, and 306 of FIG. 3 may constitute the planning phase. During the planning phase, an assessment is performed to identify validating test procedures using blockchain validating criteria and risk framework. In order to provide a required level of assurance for any given blockchain use case, a standardized acceptance criterion is developed to capture inputs and outputs and set the right assurance threshold level based on stakeholders' requirements, as needed. A blockchain risk framework can be used to identify inputs and define outputs in order to create the required level of assurance. Based on the assessment results obtained from using the criteria and risk framework of step 304, validity test and reporting parameters are determined (at step 306).

Fieldwork Phase: In some embodiments, step 308 and 310 of FIG. 3 may constitute the fieldwork phase. During the fieldwork phase, the validating software may be customized with the test and reporting parameters determined in the planning phase. Once the customized software is deployed at step 310, transactional information can be captured based on the defined data parameters and passed through a rules engine (described in further detail below), which can host the validity test rules. Practitioner uses the validity software to execute real-time evidence gathering and testing across a data activities—level data population set on a real-time basis (or some other interval if preferred, e.g., bi-monthly or monthly).

As will be described in further detail below, the software can classify testing results as either an observation (visual or virtual alert) when the rule breaks/fails, or a no-observation if the transaction passes the test rule with no breaks/fails. A practitioner classifies an observation as either an exception/deviation noted, or no exception/deviation noted. Further, the practitioner raises exception(s)/deviation(s) noted per test procedure as an issue, including exception/deviation details, investigation results, issue summaries and details, impact rankings and details, and management action plan details.

Reporting Phase: In some embodiments, step 310 of FIG. 3 may constitute the reporting phase. Once the validity tests and other fieldwork activities (i.e., exceptions/deviations and issues) are complete, the deployed tool can produce an issue and interim audit report, including ratings and details at the process and subprocess levels to achieve continuous reporting and monitoring (or some other interval if preferred, e.g., bi-monthly or monthly. In some embodiments, after the interim reporting cycle for the quarter (or some other interval if preferred) is complete, practitioner produces and issues a quarterly audit report including ratings and opinions at the process and subprocess levels to the stakeholders.

The testing and reporting can provide the required assurance level information at the process and subprocess levels based on the applicable risks, controls, testing objectives, and reporting parameters across the entire population data set to address stakeholders' needs.

In some embodiments, the exception can be replaced with the deviation in the flow described above to address the process and functional needs of the stakeholders in compliance or non-compliance areas (outside of audit).

In some embodiments, the validating methodology provides a practitioner with an end-to-end standardized audit process and sets of activities that can be used to obtain real-time transparency around given business processes (i.e., non-blockchain and blockchain) and provide compliance and audit-type reporting automatically or manually. In some embodiments, the methodology enables the practitioner to execute set of audit and compliance activities by the computer in a continuous fashion, which can bring a significant increase in efficiency and effectiveness, achieving a higher/maximum level of confidence.

In some embodiments, the blockchain validation tool/system is designed and developed to provide real-time transaction-level assurance with immediate results across a full population data set, which can be used by stakeholders and end-users simultaneously or exclusively to address their assurance, audit, and/or compliance needs. Some examples of stakeholders would be such personnel as the head of innovation, head of corporate development, chief technology officer, head of business segment(s), and chief audit executive. Some examples of end-users would be internal users (e.g., operations (first line of defense), enterprise risk management (second line of defense), internal audit (third line of defense), and tax); and external users (e.g., legal and regulatory).

Some assumptions in performing real-time assurance may include that: (1) off-chain data (i.e., data not stored within the blockchain) exists and may be required for key assurance reporting; (2) ordering, integrity, and completeness of data activities in a blockchain can be critical to assurance; (3) while the integrity of blockchain data can be validated, third-party “off-chain” data is not immutable and subject to change; and (4) assurance is being conducted on the qualitative and quantitative data activities of the blockchain, rather than the technical blockchain implementation (consensus protocols, block formation rules, blockchain forks, etc.).

The blockchain validation system may include major five components: (1) customer environment 404, (2) integration unit 406, (3) data block service unit 408, (4) front-end service or reporting unit 410, and (5) interfaces 412. In addition, the system 400 may interface with third-party computing systems (as indicated by block 402) as well as the customer blockchain 404. The following sections discuss these architectural components of the blockchain validation system (which may be referred to as the blockchain assurance and validation solution, blockchain assurance and validating software, or blockchain assurance solution).

FIG. 4 illustrates an exemplary blockchain validation system according to examples of the disclosure. The following discussion with reference to FIG. 4 outlines a structure to establish a validation node capable of performing real-time assurance off third-party blockchains. The validation system consists of individual microservices performing discrete pieces of functionality, which, when holistically viewed, can enable real-time assurance and validation of data activities in data blocks of blockchains in a blockchain network. The blockchain network may have a plurality of blockchain nodes having blockchain-based data storage systems in each blockchain node as described above with respect to FIG. 1. In some embodiments, the blockchain network and the blockchain node of FIG. 4 may be represented by the network and nodes shown in FIG. 1. The discussion below provides insight into the primary responsibilities of each service as a new blockchain event or data block is added to a node in the blockchain network.

Some assumptions in performing real-time assurance may include that: (1) off-chain data (i.e., data not stored within the blockchain) exists and may be required for key assurance reporting; (2) ordering, integrity, and completeness of data activities in a blockchain can be critical to assurance; (3) while the integrity of blockchain data can be validated, third-party “off-chain” data is not immutable and subject to change; and (4) assurance is being conducted on the qualitative and quantitative data activities of the blockchain, rather than the technical blockchain implementation (consensus protocols, block formation rules, blockchain forks, etc.).

The blockchain validation system may include major five components: (1) customer environment 404, (2) integration unit 406, (3) data block service unit 408, (4) front-end service or reporting unit 410, and (5) interfaces 412. In addition, the system 400 may interface with third-party computing systems (as indicated by block 402) as well as the customer blockchain 404. The following sections discuss these architectural components of the blockchain validation system (which may be referred to as the blockchain assurance and validation solution, blockchain assurance and validating software, or blockchain assurance solution) with reference to FIG. 4.

To illustrate the functionality of the components contained within system 400, a description of the data flow in the architecture of FIG. 4 can be pertinent. The process of validating blockchain transaction can begin with the addition of a new data block from one of the blockchain nodes 418 residing in the customer's blockchain environment. When a node 418 attempts to introduce new data into the blockchain, that activity can be sent to chain listener 422. The chain listener can serve as the initial integration point between the blockchain assurance and validation tool, and the customer blockchain. The goals of the chain listener can be to emit transactional blockchain events occurring within the blockchain. In most cases, blockchains provide varying levels of “feed” data in instances where generic events or transactions are published to subscribers of its services; in these cases, the chain listener can leverage those existing services to provide events for downstream service consumers.

Events trigger the initial action that results in a transaction or data activity (or the addition of a block) within the blockchain. Events should trigger one or more transactions within the blockchain, indicating that some key information should be delivered across the blockchain network. These transactions will manifest as a simple key-value pair, as illustrated below:

{ //on the blockchain _id: 3199444, //a unique identifier dateTime: 2103323223 //unix timestamp, transaction; 2193298439843984381212211 //a transaction, sender: John Doe, //string receiver: Jane Doe, //string amount: 10 //integer }

In most industry use-cases, blockchains will not actually store transactional data. The use of a shared ledger implies the likely scenario in which sensitive-data transactions occur. Moreover, storage costs can escalate, and blockchains are not intended to store items such as images, documents, etc. As such, an event transaction may have a simple encrypted “hash,” which can contain a secret location that can be unencrypted by the asset owner. The same object described above can easily be represented as such:

{ // on the blockchain _id: 3199444, //a unique identifier dateTime: 2103323223 //unix timestamp, hash; 2193298439843984381212211 //an encrypted value that could represent anything } { // off the blockchain (such as in a relational database). _id:2193298439843984381212211, transaction; 2193298439843984381212211 //a transaction, sender: John Doe, //string receiver: Jane Doe, //string amount: 10 //integer }

A “push” feed (built within the blockchain protocol) is the ideal setup, because it properly segregates the responsibilities across the blockchain network and the assessment and validating software. As such, it is up to the blockchain to provide guarantees that ensure transactions are emitted while the chain listener is responsible for relaying those events into the validation system. If this service is ever stopped or interrupted, it should possess enough awareness and understanding to resume starting with its last acknowledged transaction. This ensures that transactions are not “duplicated” within the environment and that unnecessary work to “reprocess” blockchain transactions will not occur.

Thus, once the chain listener detects that a new transaction is occurring on the blockchain, it can tag the event and send them to event listener 442 by placing the events onto a queue 434. The event listener 442 may then pick up the new data block from queue 434 and perform a series of tasks with the new data block acquired from queue 434. In one or more examples, the event listener 442 may store a copy of the new data block by storing in event store 436. The event store 436 can be the principal “record of truth” that represents a historical copy of the blockchain from which all downstream systems derive their system state. Records that live as unstructured data, and events transacted from the blockchain listener, will live as JSON objects within this document store (e.g., MongoDB), and will live in its nearest representation to data on the blockchain. The primary goals of the event store can be twofold: (1) separating querying and data, extraction responsibilities from the validation node (to avoid directly querying the blockchain for events); and (2) creating a consistent storage abstraction that can be leveraged regardless of the blockchain platform.

The event store can also enable additional capabilities such as data “snapshots,” where events or transactions can be “replayed” as they occur. The event log provides a strong audit capability (e.g., accounting transactions are an event source for account balances) where historic states can be recreated by replaying past events.

Simultaneously to storing the event at event store 436, the event listener 442 can transmit the new data block to data enricher 424 by placing it into a queue 432. The data enricher 424 can take the data block stored at queue 432 and request information from external data sources (e.g., from a customer or third party) through the off-chain API 426 that collects third-party data stored at 414, and off-chain data stored at 416. External data sources can be centrally managed through the use of an off-chain API 426 that can federate requests to one or many external data sources such as third party data 414 or off-chain data 416. External data sources are centrally managed through the off-chain API 426, which federates requests to one or many external data sources. Off-chain data (sometimes referred to as oracles) provide, contextual information about blockchain data, including real-time data elements (e.g., stock prices), personally identifiable or sensitive information (e.g., names or addresses), or extraneous metadata, which could bloat the size of the blockchain ledger. Through the creation of its own independent service, the application reduces the tight coupling between internal and external application logic, and limits exposure to third-party systems.

Customer environment 404 which can store off-chain data 416, as well as third party data coming from data store 414 can describe the spectrum of tasks occurring within third-party networks and the original inception of the transaction, data activities, or data block onto the blockchain-based data storage system. While upstream (i.e., actions prior to hitting the blockchain) activities should be considered “out of scope” of the tool 400—need for assurance can require that examination occurs as close to the original “source of truth” as possible—it can therefore be essential for critical data elements or keys to exist within the blockchain, or else they will not be captured by the downstream processes. Careful design of blockchain metadata is needed to enable the ability for assurance and validation. Thus, customer environment 404 can collect and store various “off-chain” data at data store 416.

As an example of off-chain data, if a distributed ledger is storing emails being sent back and forth from the customer, the names associated with each email address could be an example of “off-chain data” that could be used to help validate and audit the blockchain itself. Thus, the type of data that while not needed for action block creation itself, may be needed to validate transactions occurring in real-time can be stored at data store 416. Off-chain storage contains data that is not readily available for public consumption. Off-chain storage may reference anything from trade data to vendor/sales information, or anything that provides context to the transactions inscribed on the block.

While blockchain data is historic and immutable, off-chain data is not immutable or immune to tampering. This makes logical sense: off-chain data will likely be sensitive, business-contextual data and will often be used by multiple consumers within an organization. The duplication of data across off-chain and on-chain data which poses consistency issues and the two are in-sync. It is possible that records reflected within the blockchain are not represented off-chain. Downstream processes will need to reflect this known hazard when they are working with off-chain data by properly rebuilding or reconstructing records that require updates to ensure the audit solution accurately reflects the historic state.

Once the data enricher 424 adds in the off-chain data, it can then transmit the augmented even to rules engine 428 via queue 430. Customer-specific business assurance rules can applied to the data block in the rules engine 424. Rules can be highly specific to the business and industry concerned and be customized according to each customer as described above with respect to the risk framework. Rules can the cornerstone of the validation solution, providing the basis of when/why transactions violate specified conditions.

The rules engine 428 can be implemented as a worker with a specified set of instructions on how to apply rules against transactions. Because the user interface also relies on the awareness and knowledge of rules, the rules engine can retrieve the latest inventory of rules from a shared database (not pictured). While this extra network request may seem unnecessary, it also can enable user-features such as the dynamic toggling of rules, the addition/subtraction of rules without hard resets, etc.

Two categories of rules may be applied to transactions or data activities in the blockchain: streaming rules that assess against individual transactions, and batch rules that assess against an aggregate of transactions.

Streaming Rules: Incoming transactions can be evaluated against a set of one or many business rules that can assess validity across a variety of dimensions (e.g., completeness of a transaction, blacklisting of specific values, application of transaction logic such as input=output, etc.).

Batch Rules: Incoming transactions that possess some relationship to historical or past events can leverage the event store to identify patterns that may violate assurance rules (e.g., aging transactions, number of transactions from an account, etc.).

These rules are generators of “observations” within the solution. Observations indicate the violation of a pre-defined guideline set by business or assurance rules, which Users of the system will evaluate within the web interface. As will be described in detail below, the observations can be collected and presented to a user, who can then review each observation and determine whether the observation warrants further scrutiny.

Once the rules engine 428 applies the one or more rules to the data block, the results of the tests performed by the rules engine can be sent to reporting database 444. Reporting database can store the results of the application of the rules to the data block.

The reporting DB is the final staging area where business-oriented data structures can be queried and analyzed. Any blockchain transaction saved within the event store will create one or many transactions within the reporting DB; this will allow a variety of views to be “staged” and immediately ready for analytics, assurance reports, etc.

In order to create this reporting state for user interfaces, any off-chain data must be already “enriched” and co-located with other blockchain events. The integration of off-chain and on-chain data will require a high degree of collaboration and integration between the third party and the tool.

Reliability and uptime of external systems can be unpredictable, and the present invention anticipates “offline” scenarios where external systems are unavailable. Moreover, the current state of the reporting DB can be off-sync with its original source of truth if records have been updated within the host system.

To resolve these issues, the architecture should incorporate several precautionary measures to ensure the reporting DB is in an accurate representation of its source of truth. In the “offline” scenario, worker jobs should fail, persist, and retry to ensure transactions are not lost. Additionally, periodic background validation jobs should have the ability to check the accuracy and updates of records. This integration has the potential to be complex, depending on the auditability and traceability of third-party systems.

The results stored in reporting database 444 can be sent to user interface 412 for further evaluation via reporting API 448. The reporting platform will be the sole interface through which users interact and communicate with blockchain data. A separate “reporting API” provides external users with access into data that has already been relayed, saved, and transformed into contextual and relevant pieces of information. This information is ready to be consumed by the web interface, which enables risk assurance professionals to make decisions according to real-time events on the blockchain.

The user interface presents the results of the test procedures to the rules engine. The user interface may be a web page, a web dashboard, a mobile device, or any other device that is configured to display or output the validation report.

Referring back to FIG. 3, at step 304 a risk framework can be used to generate one or more tests. Those tests can then be transmitted to rules engine 428 in the system described in FIG. 4 to perform real-time and continuous validation of a blockchain system. The risk framework can allow for a user to specify the risks they wish to monitor for during their testing and the level of assurance they are seeking, and those inputs can be converted into a plurality tests that are run during the operation of the blockchain. Thus, while all users of the validation tool can be presented with a common risk framework, the output of the risk framework can be specific to each individual user/organization to ultimately generate a unique validation tool that addresses the specific needs of the organization.

The discussion below can illustrate how the risk framework described above can fit in with an overall approach to risk management for validating a blockchain system.

In some embodiments, determining the acceptance criteria (may be referred to as assurance threshold formula) may include the five steps discussed below.

1—Purpose (P1)—Gain an understanding of the blockchain use case, business purpose, and the resultant effect on the risks and control objectives.

2—Process (P2)—Assess on and off blockchain processes and technologies to understand continuous assurance methodology affects, up and downstream, on audit expectations and the entire process risk profile.

3—Risks (Rs)—Assess the blockchain architecture variant and identify applicable control objectives using the blockchain risk framework.

4—Stakeholder (Sr)—Identify assurance related stakeholders, determine and inventory their expectations and needs for reporting purposes.

5—Assurance Threshold Formula (ATx)—Total number of test procedures required to achieve the required level of assurance. The test procedures can be coded into the rule engine of the audit software/tool for automated testing and transaction level assurance.

Based on the results obtained from these four activities in combination of the blockchain risk framework, the following Assurance Threshold Formula (ATx) is determined:

P1+P2+Rs+Sr=ATx

The solution sum of Y (Continuous Audit) must always be equal or greater than ATx in order to create the necessary level of assurance. Therefore Y ATx.

As shown above, the risk framework (step 3) can work to provide a required level of assurance to a customer that their blockchain system is operating with minimal risk.

In some embodiments, the blockchain risk evaluation system or risk framework may assess the current state of a blockchain use case against different risk categories (e.g., six or more different risk categories) and across sub-categories (e.g., 100 or more different sub-categories) in order to address assurance and compliance needs of stakeholders. This assessment may be performed by a risk evaluation system that is industry, use case and Blockchain platform agnostic. In some embodiments, the results of these assessments provide the necessary information to identify applicable risks, control objectives, testing reporting and reporting parameters that are used to customize our the continuous validating software.

The blockchain risk framework is a component of the blockchain continuous validating solution. Due to availability and use of several variants of blockchain technology for use cases and lack of a standard approach or risk frameworks that can be used to obtain required level of transparency for a given blockchain use to meet compliance, assurance, and audit requirements, an approach has been designed and the supporting framework is developed that is industry, use case and blockchain technology variant agnostic so that practitioners across all industries and sectors can use to address the risk assurance and compliance needs independent of the blockchain technology variant and use case.

Practitioners can use blockchain risk evaluation system as a standard approach and framework to evaluate the current state of a Blockchain use case which can be inclusive of upstream and downstream (on-Blockchain and off-Blockchain) processes, technologies, and underlying data elements (people, processes, technologies) against 6 different risk categories, applicable domains, and 100+ sub-risk categories in order to address assurance and compliance needs (risks, control objectives, controls, testing objectives and procedures, and reporting parameters) of the following stakeholders simultaneously or exclusively. The risk categories, domains and sub-risk categories can be used exclusively or mutually exclusively to determine targeted and/or upstream and downstream impacts. These parameters can be used to customize and personalize an assurance or validating software/tool to achieve required level of assurance and compliance as by-product of processed transactions.

Some examples of stakeholders provided below:

-   -   Chief Executive Officer     -   Chief Financial Officer     -   Chief Technology Officer     -   Chief Information Security Officer     -   Chief Audit Executive (3rd Line of defense)     -   Head of Enterprise Risk Management (2nd line of defense)     -   Head of Operations (1st line of defense)     -   Head of Innovation     -   Head of Corporate Development     -   Head of Compliance and legal     -   Head of Tax     -   External Regulators     -   Head of Business Segment(s)

Risk Categories:

In Some Embodiments, Some Examples of Risk Categories and their relevant domains are provided in Table 1.

TABLE 1 Risk Category Domain Governance and Business Objectives Oversight Program Sponsorship Leadership Commitment MIS and Metrics Program Management Operational and Capital Expenditure Oversight Project Management Third-party Risk Cyber Security Cloud Security Data Security Data Privacy Penetration Testing Programming Security Network Security Patch and vulnerability Threat detection Threat response Infrastructure Layer Servers and Databases Configuration ITGCs Business Continuity and Disaster Recovery IT Asset Management Architecture Layer Blockchain Platform & Protocol Configuration Hardware Security Modules Signature Management Cryptography Scalability Availability Operational Layer Permissioned network management Participant Onboarding and Off-boarding Application layer Blockchain consensus program management Integration with off-Blockchain systems and processes Transactional Layer Smart Contracts Digital Assets Digital Currency Clearing and settlement Business Use Case Transactions

The sub-risk categories, control and testing objectives, test procedures and request lists for each for the above risk categories and domains of Table 1 are provided below. When engaging with the risk framework, a user using a computer/laptop or some other computing device, can be guided through each risk category and specify parameters relating to the category. In one or more examples, the user can specify if a particular risk is to be classified as low, medium, or high. In one or more examples, the categories, low, medium, high, can change for one risk, from one blockchain system to another. As an example, because there may be other surrounding controls in place or there may be some compensating controls in place, a particular risk may be categorized as low. Alternatively another in another blockchain environment, a user may assess that risk to be high because the system doesn't have certain compensating controls in place or certain processes or technology or checks and balances in place. In such a system the risk maybe categorized as high. Thus classifying a risk as low, medium, high, can mean that there's a possibility that this can fall into either of these three categories, depending on the use case and depending on the environment, that is being examined.

In some embodiments, governance and oversight risk category in the blockchain risk framework covers relevant risks, control objectives and descriptions, testing objectives and procedures, and reporting parameters designed to address assurance and compliance needs for the blockchain portfolio and program management, governance, and oversight. Focus areas for this category includes blockchain strategy, research and development, investment, business, operations, product and use case solution development activities.

The sub-risk categories, control and testing objectives, test procedures and request lists for Governance and Oversight risk category are provided below in Tables 2-4. Table 2, is an exemplary sub-risk category table for the governance and oversight risk category. The table below can be presented to a user accessing the risk framework from a computing device configured to receive inputs from a user. The table below can include a risk category indicator that specifies the category of risk as defined above. Each of the Risk Categories cover Blockchain including upstream and downstream processes, technologies stacks, and people and associated risk profiles.

The table below can include a domain column can identify the areas relevant to the blockchain that is covered by each risk category. In one or more examples, the table below can include a risk classification column that identifies the applicable processes and technologies within each domain, where the risk is present. In one or more examples, the table below can also include a risk number that simply provides a method for identifying the risk in numerical form. In one or more examples, the table below can also include a risk description that describes the risk applicable to/associated with the processes and technologies within each domain. In one or more examples, and as described above, the table can also include a risk level rating (low, medium, high) as described above.

When the user is presented with the framework, they can initially review each risk category, and specify whether such a risk is a low, medium, or high concern. Presented below is an example risk table for the government and oversight risk category.

TABLE 2 Risk Level (L, M, H) Risk Risk (As Risk Category Domain Classification Number Risk Description applicable) Governance Business Strategic, GO-BO1 At the senior management level, L, M, H and Oversight Objectives Operational, business objectives and justification is Financial, not clearly defined leading to failure Compliance, of program and misalignment with Legal, or strategy and overarching governance Reputational framework. Governance Business Strategic, GO-BO2 The Blockchain Program is L, M, H and Oversight Objectives Operational, implemented in silos without a formal Financial, oversight committee resulting in Compliance, inefficient utilization and duplication Legal, or of efforts. Reputational Governance Business Strategic, GO-BO3 Unapproved or miscommunicated L, M, H and Oversight Objectives Operational, scope can lead to failure of program or Financial, poor utilization of program resources. Compliance, Legal, or Reputational Governance Program Strategic, GO-PS1 Lack of involvement from Senior L, M, H and Oversight Sponsorship Operational, Management can lead to low Financial, organizational awareness and failure Compliance, of the Blockchain program. Legal, or Reputational Governance Program Strategic, GO-PM1 Failure to define and monitor Key L, M, H and Oversight Management Operational, Performance Indicators (KPIs) may Financial, lead to failure of the program. Compliance, Legal, or Reputational Governance Program Strategic, GO-PM2 Failure to formalize methodology for L, M, H and Oversight Management Operational, inventorying, analyzing, prioritizing Financial, and selecting eligible the Blockchain Compliance, use cases may lead to failure of the Legal, or program. Reputational Governance Program Strategic, GO-PM3 Failure to define and effectively L, M, H and Oversight Management Operational, monitor project progress may lead to Financial, failure of the program. Compliance, Legal, or Reputational Governance Program Strategic, GO-PM4 Failure to assess the level of change L, M, H and Oversight Management Operational, readiness for the organization when Financial, implementing Blockchain may lead to Compliance, failure of program. Legal, or Reputational Governance Program Strategic, GO-PM5 Failure to define the go-live criteria L, M, H and Oversight Management Operational, within the program objectives may Financial, lead to failure of the program. Compliance, Legal, or Reputational Governance Program Strategic, GO-PM6 Failure to identify proper resources to L, M, H and Oversight Management Operational, fulfill roles with the Blockchain Financial, program and lack of learning and Compliance, development to ensure that employees Legal, or skills are in line with the needs of the Reputational Blockchain program leads to excessive turnover and inadequate resources. Governance Program Strategic, GO-PM7 Failure to consider changes in the L, M, H and Oversight Management Operational, business process due to Blockchain Financial, technology could lead to loss of Compliance, institutional knowledge. Legal, or Reputational Governance Program Strategic, GO-PM8 Lack of acceptance from users and L, M, H and Oversight Management Operational, employees of the Blockchain program Financial, could lead to failure of the program. Compliance, Legal, or Reputational Governance Program Strategic, GO-PM9 Lack of acceptance from users and L, M, H and Oversight Management Operational, employees of the Blockchain program Financial, could lead to failure of the program. Compliance, Legal, or Reputational Governance Program Strategic, GO-PM10 Inadequate processes to setup L, M, H and Oversight Management Operational, Blockchain vendor software could Financial, lead to increased risks to security Compliance, requirements. Legal, or Reputational Governance Program Strategic, GO-PM11 Inadequate assessment of hardware, L, M, H and Oversight Management Operational, applications, software and software Financial, components may leave information Compliance, systems vulnerable and unable to Legal, or fulfill business objectives. Reputational Governance Program Strategic, GO-PM12 Lack of a standard process to L, M, H and Oversight Management Operational, document functional specifications for Financial, each business process can lead to Compliance, incomplete or inaccurate Legal, or documentation. Reputational Governance Program Strategic, GO-PM13 Failure to define and develop a clear L, M, H and Oversight Management Operational, benefits strategy could lead to failure Financial, of the Blockchain program. Compliance, Legal, or Reputational Governance Project Strategic, GO-PM14 Failure to assign appropriate resources L, M, H and Oversight Management Operational, to aid in the design of application Financial, security and controls may result in Compliance, increased risks to the business and Legal, or insufficient controls around the Reputational business processes. Governance Project Strategic, GO-PM15 Employees who are not appropriately L, M, H and Oversight Management Operational, trained may result in an increased risk Financial, of bypassed or forgotten Compliance, considerations essential to the Legal, or Blockchain Program. Reputational Governance Project Strategic, GO-PM16 Failure to allocate appropriate L, M, H and Oversight Management Operational, representation and resources for the Financial, duration of the program, may lead to Compliance, the misuse of organizational funds and Legal, or unintended risks to business Reputational objectives. Governance Project Strategic, GO-PM17 Lack of monitoring activities in place L, M, H and Oversight Management Operational, could lead to inaccurate and Financial, incomplete transactions processed Compliance, within the Blockchain application. Legal, or Reputational Governance Leadership Strategic, GO-LC1 Poor stakeholders and leadership L, M, H and Oversight Commitment Operational, commitment can lead to a lack of Financial, unity on program goals, objectives Compliance, and performance. Legal, or Reputational Governance MIS and Metrics Strategic, GO-MM1 Failure to allocate appropriate L, M, H and Oversight Operational, resources, while considering business Financial, requirements, may lead to the misuse Compliance, of organizational funds and Legal, or unintended risks to business Reputational objectives. Governance MIS and Metrics Strategic, GO-MM2 Inadequate controls to monitor the L, M, H and Oversight Operational, capacity, availability, and Financial, functionality of the application may Compliance, lead to interruption and/or failure to Legal, or key applications. Reputational Governance Operational and Strategic, GO-OC1 Failure to allocate appropriate L, M, H and Oversight Capital Operational, resources, while considering business Expenditure Financial, requirements, may lead to the misuse Oversight Compliance, of organizational funds and Legal, or unintended risks to business Reputational objectives. Governance Operational and Strategic, GO-OC2 Failure to allocate appropriate L, M, H and Oversight Capital Operational, resources, while considering business Expenditure Financial, requirements, may lead to the misuse Oversight Compliance, of organizational funds and Legal, or unintended risks to business Reputational objectives. Governance Operational and Strategic, GO-OC3 Failure to allocate appropriate L, M, H and Oversight Capital Operational, resources, while considering business Expenditure Financial, requirements, may lead to the misuse Oversight Compliance, of organizational funds and Legal, or unintended risks to business Reputational objectives. Governance Operational and Strategic, GO-OC4 Inadequate controls to govern and L, M, H and Oversight Capital Operational, address security risks in a project may Expenditure Financial, lead to loss of sensitive data. Oversight Compliance, Legal, or Reputational Governance Smart Contracts Strategic, GO-SC1 Blockchain software use cases are not L, M, H and Oversight Operational, consistent with participants' business Financial, or industry-specific requirements; Compliance, smart contracts cannot be effectively Legal, or leveraged for normal operations Reputational Governance Smart Contracts Strategic, GO-SC2 Blockchain implementation lacks a L, M, H and Oversight Operational, coherent governance model for Financial, development, execution, and oversight Compliance, Legal, or Reputational Governance Smart Contracts Strategic, GO-SC3 Lack of IP safeguards compromise the L, M, H and Oversight Operational, organization's DLT innovations Financial, Compliance, Legal, or Reputational

After categorizing the risks as described above, the framework can then present the user with series of control/test objectives (with corresponding descriptions) which the user can review and determine whether such controls/test objectives should be considered in-scope to the audit or out of scope to the audit. An exemplary control/test objective table is provided below for the governance and oversight risk category.

TABLE 3 In-scope/Out- of-Scope Risk (TBD - As per Category Domain Control/Test Objective Control Description engagement) Governance Business At the senior management level, The Blockchain Program Charter is In-scope and Oversight Objectives business justification and created and includes specific details of objectives for the Blockchain goals and business objectives of the Program is documented and overall Blockchain Program. The aligns with business strategy. Blockchain steering committee reviews The Blockchain Program is and approves The Blockchain Program considered in the overarching Charter to ensure it is in alignment with governance framework with the firm's organizational and alignment to risk, compliance governance strategies. and IT/data frameworks. Governance Business The Blockchain Program is A Blockchain steering committee, In-scope and Oversight Objectives appropriately prioritized against which includes executive leadership other initiatives within the and senior members of the business, organization. risk, compliance and the Blockchain program management, meets on a quarterly basis to conduct business performance reviews of how the Blockchain Program aligns with business strategy. Governance Business The Blockchain program project The scope of the Blockchain program is In-scope and Oversight Objectives plan has been defined outlined in the Blockchain project addressing each phase of the plan/roadmap. The project plan is Blockchain program project and reviewed and approved by the steering is consistent with the scope and committee to ensure the plan is in objectives defined within the alignment with the Blockchain Program program charter. The scope of Charter. the Blockchain Program has been approved and communicated by all participants. Governance Program Senior Management is actively The Blockchain Program Charter is In-scope and Oversight Sponsorship involved in creating created and includes specific details of organizational awareness, the communication strategy to the championing the Blockchain broader organization. The Blockchain program. steering committee reviewed and approved The Blockchain Program Charter. Governance Program Key Performance Indicators Key Performance Indicators (KPIs) are In-scope and Oversight Management (KPIs), specific to the established to monitor the Blockchain Blockchain use case, to monitor program performance. program performance have been developed. Governance Program Formalized methodology for The Blockchain program policies and In-scope and Oversight Management inventorying, analyzing, procedures, which includes prioritizing and selecting methodology for inventorying, eligible the Blockchain use analyzing, prioritizing and selecting cases exists. This method is eligible the Blockchain use cases, are formally documented to ensure reviewed and approved on a periodic consistently across business basis. units that may potentially utilize the technology. Governance Program The Blockchain program project The Blockchain Program steering In-scope and Oversight Management plan has been defined committee reviewed and approved The addressing every phase of the Blockchain program project plan. The Blockchain program project and Blockchain program management is consistent with the scope and monitors individual project work plans objectives defined within the to measure progress against The program charter. Individual Blockchain project plan. project work plans are well defined and effectively monitored for project progress; an integrated master plan that provides a comprehensive view of work effort and dependencies across all project teams has been defined. Governance Program Affected stakeholders are The processes selected for Blockchain In-scope and Oversight Management actively involved in the implementation are evaluated on a planning process and the quarterly basis by the Blockchain Blockchain Program team has program management team to ensure formally assessed the level of the Blockchain technology is being change readiness for the optimized and decisions adhere to the organization and its business Blockchain selection criteria outlined in units, stakeholders, and the Blockchain program policies and customers. procedures. The results of this evaluation are reported to the Blockchain steering committee. Governance Program Formal go-live criteria for each Formal policies and procedures have In-scope and Oversight Management application/use case is been established and documented to adequately linked back to the outline the methodology for the program scope and objectives. Blockchain configuration and maintenance, including decision making criteria to go live being formally documented. Policies and procedures are reviewed and approved on a periodic basis. Governance Program Management has updated The Blockchain program policies and In-scope and Oversight Management staffing and hiring practices to procedures, which includes details of ensure the right people within the formal the Blockchain organization the organization are identified structure, staffing and training and assigned as the Blockchain requirements are reviewed and program resources. Learning approved on a periodic basis. and development personnel have been engagement to ensure training program has been instituted to train the Blockchain Program staff. Governance Program There has been adequate Periodically, management performs a In-scope and Oversight Management considerations for loss of risk assessment of the Blockchain institutional knowledge as the technology and evaluates the risk Blockchain technology alters/ associated with loss of institutional eliminates steps in business knowledge. processes. Governance Program There is adequate Management has considered the impact In-scope and Oversight Management considerations for the that the Blockchain program will have organizations resistance to on resources and has designed a formal change and appropriate people people and change process to mitigate and change management possible disruptions and resistance processes are put into place to across the organization. clearly articulate the future state and address possible disruption discomfort with a new technologically sophisticated process that will result in large decreases in manpower requirements. Governance Program A formal process to address The Blockchain Program Charter In-scope and Oversight Management organizational changes, outlines a formal process to address including the ability to perform organizational changes. The tasks in case of the Blockchain organizational change process is failure. analyzed and evaluated on a monthly basis by the Blockchain program management team. The results of this evaluation are reported to The Blockchain steering committee. Governance Program The setup of the Blockchain The Blockchain vendor software for In-scope and Oversight Management vendor software includes initial integration into the firm's consideration of new security environment follows a well-defined requirements to maintain integration plan and is monitored by the confidentiality, integrity, and Blockchain program management. availability have been considered. Governance Program Hardware (including Impact of software integration on the In-scope and Oversight Management configurations, locations, firm's existing hardware configurations, capacity/capacity utilization, software and applications is and age and data requirements), documented and evaluated. The results applications, software and of this evaluation are reported to the software components impacted Blockchain Program steering by the Blockchain integration committee. have been identified, evaluated and reported on. Governance Program The process to create functional The Blockchain program policies and In-scope and Oversight Management specifications for each new procedures, which includes the process Blockchain business process to create functional specifications for follows a standard process each new the Blockchain business documented in the Blockchain process, are reviewed and approved on Program policies and a periodic or as needed basis. procedures. Governance Program A benefits realization strategy The Blockchain Program Charter is In-scope and Oversight Management has been developed and created and includes the Blockchain approved. Benefits Management process. The Blockchain Program steering committee reviews and approves the Blockchain Program Charter to ensure it is in alignment with the firm's organizational and governance strategies. Governance Project Appropriate members of the The Blockchain program management In-scope and Oversight Management business, the Blockchain team includes members from risk and program team, risk, and compliance responsible for designing compliance are actively and implementing key controls being involved in design of executed by the Blockchain application security and technology. The functional controls. specifications for each new the Blockchain business process are reviewed by the Blockchain Program risk & compliance team member to assure the appropriateness of the design and operating effectiveness of controls the Blockchain is executing. Governance Project Individuals are properly trained The Blockchain Program configuration In-scope and Oversight Management to configure the Blockchain analysts are required to complete technology. training prior to being involved with functional or technical Blockchain design. On an ongoing basis, individuals involved in the Blockchain program receive updated education to keep current with emerging technology issues. Governance Project There is adequate commitment The Blockchain policies and In-scope and Oversight Management to provide appropriate procedures are defined and include a representation and resources for description of key Blockchain program the duration of the Blockchain management positions, responsibilities program. and overall organization structure for governance. Governance Project Post implementation, there are Post implementation reviews are In-scope and Oversight Management monitoring activities in place to performed by the required business monitor the completeness and and/or technology management or accuracy of processing for the designee to test the completeness and Blockchain transactions. accuracy of processing for the Blockchain transactions. Governance Leadership The Blockchain program Leadership discusses and engages with In-scope and Oversight Commitment stakeholders have been the business to determine Blockchain adequately engaged and goals and objectives. The Blockchain understand the Blockchain Program Charter is created and program goals and objectives. includes specific details of goals and business objectives of the overall the Blockchain Program. The Blockchain steering committee reviews and approves The Blockchain Program Charter to ensure it is in alignment with the firm's organizational and governance strategies. Governance MIS and There is a formal process for The Blockchain project plan/roadmap In-scope and Oversight Metrics monitoring the Blockchain details the financial needs of each program project performance individual project work stream. The and details of performance is Blockchain program management has a communicated to appropriate formal process to monitor project costs stakeholders. as it relates to project progress, milestones, and deliverables, as well as specifics to measure KPI, ROI per process and overall ROI. Monthly, the project costs are reported back to the Blockchain steering committee. Governance MIS and There is sufficient oversight Daily, the Blockchain Operational In-scope and Oversight Metrics over the application by to management reviews capacity, ensure the Blockchain is logged, availability and performance metrics of functioning, and workloads, the Blockchain in production. availability and capacity are Deviations from standard metrics are being efficiently and effectively noted, researched and resolved. balanced. Monthly these metrics are report to the Blockchain Program steering committee. Governance Operational and Financial needs of the program The Blockchain Program Charter is In-scope and Oversight Capital have been reviewed and created and includes the financial needs Expenditure approved by senior management of the Blockchain program. The Oversight and assessment of those needs Blockchain steering committee reviews are reassessed on an ongoing and approves the Blockchain Program basis. Charter. Additionally, the Blockchain project plan/roadmap details the financial needs of each individual project work stream. Governance Operational and The organization allocates The organization establishes a plan for In-scope and Oversight Capital appropriate resources to the allocation of appropriate resources Expenditure information security and risk to projects and programs based on Oversight management. assessing organizational, operational, and strategic considerations. Governance Operational and The organization allocates Resources (human, technology, In-scope and Oversight Capital appropriate resources to finance) required to achieve security Expenditure information security and risk objectives are allocated for the Oversight management. establishment, implementation, maintenance and continual improvement of the information security management system. Governance Operational and Implement security controls in Information security is addressed in In-scope and Oversight Capital projects. project management, regardless of the Expenditure type of the project. Oversight

Finally once the user has identified the risks (including their particular levels), and has determine which test objectives are in-scope and out-of-scope to the validation, the risk framework can then provide the user with the applicable tests that will be applied to the user's blockchain validation system. The table below can be created based on the user's inputs to the reference framework described above. The table below can indicate the test procedures to be performed that determine the design or operating effectiveness of a control specified in table 3. The table below can also specify the test type which can be inquiry, inspection and observation, as well as attribute or substantive type of testing using a manual or automated approach. Finally, the table below can also present the user with a request list that can show the user requested items to be gathered to provide supporting information such as documentation or evidence including data parameters to execute test procedures in order to obtain the specified level of assurance and confidence surrounding the process and technology.

TABLE 4 Test Type (TBD - As Risk per Category Domain Test Procedure (#) engagement) Request List (#) Governance Business 1. Verify the Blockchain Program Inquiry, 1. Blockchain Program Charter and Objectives Charter has been created and review Inspection, 2. Meeting minutes from the Steering Oversight the overall goals and business and/or committee meeting where the Blockchain objectives. observation Program charter was reviewed. 2. Inspect the Blockchain Program Charter to ensure the Steering committee has reviewed and approved it. Governance Business 1. Inquire with Blockchain steering Inquiry, 1. Meeting minutes from the Steering and Objectives committee members to determine Inspection, committee where business performance Oversight criteria for business reviews to and/or reviews of how the Blockchain Program assess the Blockchain program's observation aligns with business strategy are discussed alignment with business strategy and reviewed. 2. Inspect Quarterly meeting minutes to confirm that business performance reviews were conducted by the established criteria. Governance Business 1. Inspect the Blockchain project Inquiry, 1. Blockchain project plan/roadmap and Objectives plan/roadmap to confirm that scope Inspection, 2. Blockchain Program Charter Oversight of program is outlined. and/or 3. Meeting minutes from the Steering 2. Inquire with Steering committee observation committee where project plan/roadmap was to ensure that plan was reviewed reviewed and approved. and approved, as evidence that plan is in line with Blockchain Program Charter. Governance Program 1. Inquire and inspect the Inquiry, 1. Blockchain Program Charter and Sponsorship Blockchain Program Charter to Inspection, 2. Evidence that the Blockchain Program Oversight confirm details regarding the and/or Charter was reviewed and approved. communication strategy to the observation broader organization. 2. Inspect that the Blockchain Program Charter has been reviewed and approved. Governance Program 1. Inquire with Blockchain Inquiry, 1. Blockchain Program KPIs and Management Operational Management to ensure Inspection, Oversight Key Performance Indicators (KPIs) and/or have been established and observation monitored. 2. Inspect evidence to determine KPIs are monitored periodically. Governance Program 1. Inquire with management on Inquiry, 1. Blockchain program policies and and Management methodology for inventorying, Inspection, procedures. Oversight analyzing, prioritizing and selecting and/or 2. Evidence of review and approval on a eligible the Blockchain use cases. observation periodic basis of the Blockchain program 2. Obtain and inspect Blockchain policies and procedures. program policies and procedures and confirm that methodology for inventorying, analyzing, prioritizing and selecting eligible the Blockchain use cases is included. 3. Inquire with management and inspect that program policies and procedures are reviewed and approved on a periodic basis. Governance Program 1. Inquire with Steering committee Inquiry, 1. Blockchain Program Charter and Management to ensure that plan was reviewed Inspection, 2. Meeting minutes from the Steering Oversight and approved, as evidence that plan and/or committee meeting where the Blockchain is in line with Blockchain Program observation Program charter was reviewed. Charter. 3. Blockchain Project Plan 2. Inquire with the Blockchain program management to determine the criteria of monitoring the individual project work plans to ensure the progress is measured against the Blockchain project plan. Governance Program 1. Inquire with the Blockchain Inquiry, 1. Blockchain Program Charter (policies and Management program management team to Inspection, and procedures) Oversight determine that the Blockchain and/or 2. Evidence of Blockchain selection criteria implementation processes are observation within the Blockchain Program Charter evaluated on a quarterly basis and 3. Blockchain implementation processes to ensure they adhere to the 4. Blockchain implementation evaluation Blockchain selection criteria report outlined in the Blockchain Program Charter. 2. Inquire with Steering Committee to ensure they receive the evaluation of the Blockchain implementation processes. Governance Program 1. Inspect the Blockchain Inquiry, 1. Blockchain Configuration and and Management Configuration and Maintenance Inspection, Maintenance Methodology Oversight methodology to ensure formal and/or 2. Evidence of decision making criteria to policies and procedures have been observation go live documented and include decision 3. Evidence of review and approval of the making criteria to go live. Blockchain Configuration and Maintenance 2. Inspect the Blockchain Methodology on a periodic basis Configuration and Maintenance methodology to ensure the policies and procedures have been reviewed and approved on a periodic basis. Governance Program 1. Obtain and inspect the Inquiry, 1. Blockchain program policies and and Management Blockchain program policies and Inspection, procedures Oversight procedures, and review for details and/or 2. Evidence of review and approval on a of the formal the Blockchain observation periodic basis of the Blockchain program organization structure, staffing and policies and procedures. training requirements. 2. Inquire with management and inspect the policies and procedures to confirm that they have been reviewed and approved on a periodic basis. Governance Program 1. Inquire with management about Inquiry, 1. Risk assessment performed by and Management the process to evaluate the risks Inspection, management Oversight regarding loss of institutional and/or knowledge. observation 2. Obtain and inspect the risk assessment performed by management, review that the risk has been evaluated. Governance Program 1. Inquire with management about Inquiry, 1. Formal people and change process and Management the people and change process. Inspection, document Oversight 2. Obtain and inspect the formal and/or people and change process. observation Governance Program 1. Inquire with management Inquiry, 1. Blockchain Program Charter and Management regarding the formal process to Inspection, 2. Evidence that evaluation of the change Oversight address organizational changes. and/or process is evaluated and presented to the 2. Obtain and inspect the observation Blockchain steering committee. Blockchain Program Charter to confirm that is outlines a formal process to address organizational changes. 3. Inquire with the Blockchain program management team to confirm that the change process is analyzed and evaluated on a monthly basis. 4. Inquire with Blockchain steering committee to confirm that results of the evaluation are reported. Governance Program 1. Inquire with management on the Inquiry, 1. Integration procedures for vendors and Management integration procedure in place for Inspection, Oversight new vendor software. and/or 2. Obtain and inspect the integration observation plan and review to confirm that the Blockchain program management team Governance Program 1. Inquire with management on the Inquiry, 1. Documentation and evaluation of and Management documentation and evaluation of Inspection, hardware, applications, software and Oversight hardware, applications, software and/or software components related to the and software components related to observation Blockchain the Blockchain. 2. Evidence of evaluation reported to the 2. Obtain and inspect the formal Blockchain Program steering committee. documentation and evaluation of hardware, applications, software and software components related to the Blockchain. 3. Inspect evidence that the results of the evaluation are presented and reported to the Blockchain Program steering committee. Governance Program 1. Inquire with management on Inquiry, 1. Policies and procedures to create the and Management policies and procedures to create the Inspection, functional specifications. Oversight functional specifications. and/or 2. Evidence that the process was reviewed 2. Obtain and inspect the policies observation and approved. and procedures to create the functional specifications. 3. Inspect evidence that the process is reviewed and approved on a periodic or as needed basis. Governance Program 1. Inquire and inspect the Inquiry, 1. Blockchain Program Charter and Management Blockchain Program Charter to Inspection, 2. Evidence that the Blockchain Program Oversight confirm details regarding the and/or Charter was reviewed and approved. Benefits Management process. observation 2. Inspect that the Blockchain Program Charter has been reviewed and approved by the Blockchain program steering committee. Governance Project 1. Inquire with management on the Inquiry, 1. Functional specifications and Management process and appropriateness of Inspection, 2. Evidence that employees involved in the Oversight resources used to design functional and/or design are appropriate and possess the specifications and confirm that they observation proper qualifications are reviewed by the Blockchain program risk and compliance team. 2. Inspect functional specifications to assure appropriateness of the design and operating effectiveness of controls. Governance Project 1. Inquire with management about Inquiry, 1. Training plan and Management the training requirements for Inspection, 2. Training materials Oversight analysts involved with the and/or functional and/or technical design. observation 2. Inspect training plan or training materials provided to analysts, including any on-going training. Governance Project 1. Inquire with management on Inquiry, 1. Policies and procedures that provide a and Management policies and procedures that provide Inspection, description of key Blockchain program Oversight a description of key Blockchain and/or management positions, responsibilities and program management positions, observation overall organization structure for responsibilities and overall governance. organization structure for governance. 2. Obtain and inspect the policies and procedures that provide a description of key Blockchain program management positions, responsibilities and overall organization structure for governance. Governance Project 1. Inquire with management on the Inquiry, 1. Reviews performed to test completeness and Management reviews performed to test Inspection, and accuracy of processing for the Oversight completeness and accuracy of and/or Blockchain transactions. processing for the Blockchain observation transactions. 2. Obtain and inspect the reviewed performed to test completeness and accuracy of processing for the Blockchain transactions. Governance Leadership 1. Verify the Blockchain Program Inquiry, 1. Blockchain Program Charter and Commitment Charter has been created and review Inspection, 2. Meeting minutes from the Steering Oversight the overall goals and business and/or committee meeting where the Blockchain objectives. Review the members of observation Program charter was reviewed. the organization who have contributed to the Blockchain Program Charter to confirm appropriate leadership engagement. 2. Inspect the Blockchain Program Charter to ensure the Steering committee has reviewed and approved it. Governance MIS and 1. Inspect the Blockchain project Inquiry, 1. Blockchain Project Plan/roadmap and Metrics plan/roadmap to confirm the Inspection, 2. Evidence of formal process to monitor Oversight financial needs are outlined. and/or and report project costs 2. Inquire with the Blockchain observation 3. Evidence of performance metrics program management to determine there is a formal process to monitor project costs and measure performance in place. 3. Inquire with the Blockchain steering committee to ensure the project costs are reported to them on a monthly basis. Governance MIS and 1. Obtain daily Blockchain Inquiry, 1. Daily Blockchain Capacity, Availability, and Metrics capacity, availability, and Inspection, and Performance Metrics Oversight performance metrics. and/or 2. Evidence of daily review of the metrics 2. Inquire with Blockchain observation by the Blockchain Operational Operational Management to Management determine the criteria for reviewing 3. Evidence of reporting the metrics to the the metrics daily and inspect the Blockchain Program Steering Committee evidence to ensure the metrics are reviewed daily and if there are deviations they are noted, researched and resolved. 3. Inspect the evidence of the metrics to ensure they are reported monthly to the Blockchain Program Steering Committee. Governance Operational 1. Inquire with the Blockchain Inquiry, 1. Blockchain Program Charter and and Capital steering committee members to Inspection, 2. Meeting minutes from the Steering Oversight Expenditure determine criteria for financial and/or committee meeting where the Blockchain Oversight needs are included in the observation Program charter was reviewed. Blockchain Program Charter. 3. Blockchain Project Plan/Roadmap 2. Inspect the Blockchain Program 4. Evidence of each individual Blockchain Charter to ensure the Steering project work stream's financial needs committee has reviewed and approved it. 3. Inspect the Blockchain Project Plan/Roadmap to ensure the financial needs of each individual project work stream is included and outlined. Governance Operational 1. Obtain a copy of the Inquiry, 1. Organizations plans and/or documents and and Capital organizations process and/or plans Inspection, for allocation of funds Oversight Expenditure for allocating resources and verify it and/or Oversight takes the following factors into observation consideration: people, skills, experience and competence; resources needed for each step of the risk management process; the organization's risk processes, methods and tools to be used for managing risk; documented processes and procedures; information and knowledge management systems; training programs. Governance Operational 1. Inquire with the control owner Inquiry, 1. Documentation for the most recent and and Capital and confirm if the organization has Inspection, annual budget planning exercise. Oversight Expenditure processes in place to identify and/or 2. Evidence that the organization has Oversight additional expertise needed to observation processes in place to identify additional improve information security expertise needed to improve information defenses. security defenses. 2. Determine if the size and quality 3. Provide a list the organization's security of the organization's security staff staff, including their positions and is adequately staffed and structured expertise. handle the impact of staff turnover. Governance Operational 1. Inquire with management how Inquiry, 1. Project management methodology or and and Capital security is embedded in the project Inspection, process documentation. Oversight Expenditure management process/lifecycle. and/or 2. Population: System extract or register of Oversight 2. Obtain project methodology or observation projects process documentation and validate 3. For a sample of projects selected, that it considers security risks as evidence of risk assessment activities being part of the process. performed as part of the project management lifecycle. 4. ISMS manual - Description of the security requirements department managers are to include in projects.

In some embodiments, cybersecurity risk category in the blockchain risk framework covers relevant risks, control objectives and descriptions, testing objectives and procedures, and reporting parameters designed to address assurance and compliance surrounding the cybersecurity and privacy management activities.

The sub-risk categories, control and testing objectives, test procedures and request lists for Cyber Security risk category are provided below in Tables 5-7. The tables below are formatted in the same manner as tables 2-4 described above, and thus for an explanation of each column below, the corresponding discussion above can be referenced.

TABLE 5 Risk Level (L, Risk Risk M, H) Risk Category Domain Classification Number Risk Description (As applicable) Cyber Security Cloud Security Strategic, CS-CS1 Without clearly defined roles L, M, H Operational, and responsibilities with cloud Financial, service providers and SLA in Compliance, place, accountability is lost Legal, or when issues in the relationship Reputational arise. Cyber Security Cloud Security Strategic, CS-CS2 Without clearly defined roles L, M, H Operational, and responsibilities with cloud Financial, service providers and SLA in Compliance, place, accountability is lost Legal, or when issues in the relationship Reputational arise. Cyber Security Cloud Security Strategic, CS-CS3 Lack of established and L, M, H Operational, implemented safeguards may Financial, lead to supply chain Compliance, information, system component, Legal, or and information system Reputational vulnerabilities Cyber Security Cloud Security Strategic, CS-CS4 Lack of adherence to the L, M, H Operational, documented production Financial, network standards may lead to Compliance, increased security risk. Legal, or Reputational Cyber Security Cloud Security Strategic, CS-CS5 Unauthorized access of L, M, H Operational, information stored in shared Financial, resources can result in Compliance, inappropriate access, changes or Legal, or loss. Reputational Cyber Security Data Security Strategic, CS-DS1 Data exchanged through L, M, H Operational, communication facilities may Financial, be intercepted and accessed by Compliance, unauthorized agents within or Legal, or outside the organizations Reputational network. Cyber Security Data Security Strategic, CS-DS2 Procedures which do not L, M, H Operational, facilitate appropriately Financial, classifying, labeling and Compliance, handling information based on Legal, or its value, business and legal Reputational requirements may expose information to deliberate or accidental misuse. Cyber Security Data Security Strategic, CS-DS3 Lack of controls to protect L, M, H Operational, information can lead to data Financial, leaks or exposures that threaten Compliance, the organization's reputation Legal, or and could lead to litigation. Reputational Cyber Security Data Security Strategic, CS-DS4 Lack of alignment with the L, M, H Operational, organization's risk strategy and Financial, risk appetite in the protection of Compliance, data may compromise the Legal, or confidentiality, integrity and Reputational availability of information in Blockchain systems. Cyber Security Data Security Strategic, CS-DS5 Failure to establish and L, M, H Operational, communicate policies and Financial, procedures for information Compliance, security relevant to Blockchain Legal, or use case may result in gaps in Reputational security capabilities needed to reduce the organization's cyber risk exposure in accordance with its risk appetite. Cyber Security Data Privacy Strategic, CS-DP1 Lack of controls to protect L, M, H Operational, information can lead to data Financial, privacy or exposures that Compliance, threaten the organization's Legal, or reputation and could lead to Reputational litigation. Cyber Security Data Privacy Strategic, CS-DP2 Failure to establish and L, M, H Operational, communicate policies and Financial, procedures for privacy may Compliance, result in gaps in privacy Legal, or capabilities needed to reduce Reputational the organization's privacy risk exposure in accordance with its risk appetite. Cyber Security Data Privacy Strategic, CS-DP3 Lack of a privacy policy may L, M, H Operational, increase the risk that Financial, information is disclosed or used Compliance, without the owner's consent, Legal, or resulting in litigation and Reputational reputational damage. Cyber Security Penetration Strategic, CS-PT1 Inadequately defined processes L, M, H Testing Operational, for technical vulnerability Financial, management and ineffective Compliance, testing or detection of Legal, or vulnerabilities may result in Reputational inappropriate or unauthorized access to information. Cyber Security Network Strategic, CS-NS1 Failure to protect network L, M, H Security Operational, perimeter may result in Financial, unauthorized access. Compliance, Legal, or Reputational Cyber Security Patch and Strategic, CS-PVM1 Lack of proper information L, M, H Vulnerability Operational, system management flaw Management Financial, management may result in Compliance, security vulnerabilities Legal, or Reputational Cyber Security Patch and Strategic, CS-PVM2 Inadequately defined processes L, M, H Vulnerability Operational, for technical vulnerability Management Financial, management and ineffective Compliance, testing or detection of Legal, or vulnerabilities may result in Reputational inappropriate or unauthorized access to information. Cyber Security Patch and Strategic, CS-PVM3 Inadequate processes for system L, M, H Vulnerability Operational, updates and patch management Management Financial, may result in compromise of Compliance, system security due to the latest Legal, or updates and patches not being Reputational installed in a timely manner. Cyber Security Threat Strategic, CS-TD1 The lack of logging L, M, H Detection Operational, mechanisms results in the Financial, inability to track unauthorized Compliance, activity. Legal, or Reputational Cyber Security Threat Strategic, CS-TD2 Inadequate processes for L, M, H Detection Operational, logging and monitoring Financial, Blockchain system activities Compliance, may result in unauthorized Legal, or information processing Reputational activities going undetected. Cyber Security Threat Strategic, CS-TD3 Lack of monitoring mechanisms L, M, H Detection Operational, may result in breaches and Financial, sensitive data exposure. Compliance, Legal, or Reputational Cyber Security Threat Response Strategic, CS-TR1 Absence of a formalized L, M, H Operational, Security Incident Response Financial, Program may result in Compliance, uncoordinated processes in Legal, or response to a security incident. Reputational Cyber Security Threat Response Strategic, CS-TR2 Absence of a formalized L, M, H Operational, Security Incident Response Financial, Program may result in Compliance, uncoordinated processes in Legal, or response to a security incident. Reputational Cyber Security Threat Response Strategic, CS-TR3 Incidents that are not controlled L, M, H Operational, may lead to pervasive problems Financial, throughout the organization. Compliance, Legal, or Reputational Cyber Security Programming Strategic, CS-PS1 In adequate security measures L, M, H Security Operational, within the development Financial, lifecycle of information systems Compliance, may lead to unauthorized Legal, or changes. Reputational Cyber Security Programming Strategic, CS-PS2 Systems with vulnerabilities L, M, H Security Operational, may be developed and Financial, implemented in the production Compliance, environment. Legal, or Reputational Cyber Security Programming Strategic, CS-PS3 Systems with vulnerabilities L, M, H Security Operational, may be developed and Financial, implemented in the production Compliance, environment. Legal, or Reputational Cyber Security Programming Strategic, CS-PS4 Systems with vulnerabilities L, M, H Security Operational, may be developed and Financial, implemented in the production Compliance, environment. Legal, or Reputational Cyber Security Programming Strategic, CS-PS5 Untested changes may lead to L, M, H Security Operational, interruption and/or unintended Financial, consequences to the Compliance, organization. Legal, or Reputational Cyber Security Programming Strategic, CS-PS6 Insecure coding practices, L, M, H Security Operational, especially within the application Financial, layer, can introduce security Compliance, vulnerabilities and increase the Legal, or risk to internal and external Reputational threats. Cyber Security Programming Strategic, CS-PS7 Use of production or live data L, M, H Security Operational, for development and/or testing Financial, purposes can cause unintended Compliance, corruption or manipulation of Legal, or the data. Reputational Cyber Security Smart Contracts Strategic, CS-SM1 Input validation mechanisms for L, M, H Operational, fields and records are not in Financial, place, creating the risk of failed Compliance, conversion of data from input to Legal, or outputs Reputational

TABLE 6 In-scope/Out-of- Scope Control/Test (TBD - As per Risk Category Domain Objective Control Description engagement) Cyber Security Cloud Security Contracts with the Cloud Contracts between the Cloud In-scope Service provider specify Service Provider and the required information organization specifies appropriate security and processing security and processing measures, measures. and establish data are not processed for any non-specified purpose without approval. Cyber Security Cloud Security Cloud service providers A contract is signed between both In-scope and understand roles & parties detailing the roles and responsibilities, responsibilities of each party, including requirements to including information security address information requirements, confidentiality/non- security risks for disclosure agreements, confidentiality, and the obligations, and the obligations of secure transfer of employees and subcontractors. information. Cyber Security Cloud Security The organization Organizational safeguards such as In-scope employs measures to the identification, management protect against supply and reduction of vulnerabilities chain threats from cloud are employed to protect the service providers that supply chain against information impact the Blockchain system, system components, and information system, information system services system component, or threats. information system service. Cyber Security Cloud Security Cloud services are Secure standardized network In-scope secured using standard protocols are in place to manage network protocols, and the cloud service and interoperability and documentation detailing relevant portability standards are interoperability and portability available to customers. standards are made available to customers. Cyber Security Cloud Security Blockchain systems are The Blockchain system are In-scope configured to prevent configured to prevents unauthorized access and unauthorized and unintended transfer of information information transfer via shared through shared system system resources. Re-use of resources. shared resources is monitored and controlled to prevent unauthorized access. Cyber Security Data Security Data exchange is Formal information exchange In-scope controlled, encrypted, requirements have been and protected while the established and Blockchain information is at rest or systems are configured to protect transferred between the exchange of information systems. through the use of all types of communication facilities and interfaces. Cyber Security Data Security Resources (e.g., Information assets (e.g., In-scope hardware, devices, data, hardware, devices, data, and and software) are software) are classified based on classified based on their their criticality and sensitivity. criticality and business Information is handled and value. protected in accordance with its classification, criticality, and business value to the organization. Cyber Security Data Security Protections against data The organization employs data In-scope leaks are implemented. mining prevention and detection techniques for data storage objects supporting Blockchain use case to adequately detect and protect against data mining. Cyber Security Data Security Data in Blockchain Information and records (data) in In-scope systems is protected Blockchain systems are managed according to the risk consistent with the organization's strategy and risk appetite risk strategy to protect the of the organization. confidentiality, integrity, and availability of information. Cyber Security Data Security Policies and procedures Information security policies and In-scope for direction and support applicable procedures have been of organizational systems formally documented in and applications exist in accordance with organization's accordance with business risk objectives, applicable legal requirements and and regulatory requirements, have relevant laws and been approved by Management, regulations. and have been communicated to all employees and relevant external parties. The policies and procedures are reviewed on a periodic basis based on changes to the internal and external environment and to support management's objective of continuous improvement of the organization's information security capabilities. Cyber Security Data Privacy Protections against data Unauthorized leaks of data, In-scope privacy are implemented specifically PII and PHI, are in Blockchain systems to prevented or detected. The prevent unauthorized processor prevents or monitors view or exposures of for unauthorized leakage of data, confidential information. or enables the capability for its customers to prevent or monitor for the unauthorized leakage of data. DLP tools monitor outbound communications traffic at the external boundary of the information system (i.e., system perimeter) and at interior points within the system (e.g., subsystems, subnetworks) to detect covert exfiltration of information. Cyber Security Data Privacy Policies and procedures Information security policies and In-scope for direction and support procedures around information of information privacy privacy are documented and exist in accordance with available to personnel on business requirements accessible resources. The policies and relevant laws and and procedures are regulations. reviewed/updated periodically. Cyber Security Data Privacy The organization The privacy policy discloses the In-scope discloses how it uses PII ways that the organization in accordance with the gathers, uses, discloses, and public notice manages PII. It fulfills the legal requirement. requirement to protect PII and declares the company's policy on how it collects, stores, and releases the PII it collects, and inform whether PII is kept confidential, shared with partners, or sold to other firms or enterprises. Cyber Security Penetration Asset vulnerabilities are Penetration tests of the In-scope Testing monitored, identified and production environment are documented. performed on a periodic basis or after any significant infrastructure or application upgrade or modification. Remediation plans are developed to address the risks. The penetration testing methodology aligns with industry standard practices and covers application-layer and network- layer. Testing is performed both inside and outside the network. Test results are retained for a specific period of time. Cyber Security Network Network perimeter is Firewalls and routers are In-scope Security protected using managed configured to: boundary protection Restrict inbound and outbound devices. traffic to that which is necessary (e.g., deny by default, permit by exception) Restrict connections between untrusted networks and any system components Fail securely in case of an operational failure Permit only authorized traffic between wireless environment and cardholder data environment Firewall and router configuration standards are in place to define network connection requirements. The firewall and router configuration standards include the following: Business justification and approval for use of all services, protocols, and ports allowed, including security features implemented for those protocols considered to be insecure (e.g., FTP, Telnet, POP3, IMAP, and SNMP v1 and v2) Roles and responsibilities for management of network components. Exceptions to the standards are documented and reviewed on a periodic basis. There is a formal process for testing and approval of all network connections and changes to firewall and router configurations. For any public-facing Web applications, an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) has been installed, to continually check all traffic. A DMZ is implemented to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports. Inbound Internet traffic is limited to IP addresses within the DMZ. A firewall is required at each internet connection and between any DMZ and the intranet. The information system routes internal communications traffic to external networks through authenticated proxy servers (e.g., web content filters with a defined list of authorized and unauthorized websites) Anti-spoofing measures are implemented to detect and block forged source IP addresses from entering the network. Cyber Security Patch and Identify, report and A vulnerability management In-scope Vulnerability correct information program exists to identify and Management systems flaws in a timely manage vulnerabilities in a manner. centralized, streamlined and organized manner. The technical vulnerability management program is evaluated on a quarterly basis. Cyber Security Patch and System vulnerability Vulnerability scans and rescans In-scope Vulnerability scanning is performed to are performed by qualified Management identify threats. personnel on both external and internal facing production systems using internal scanning resources on a periodic basis and when new vulnerabilities affecting the systems are known. Commercial and proprietary vulnerability scanning tools are configured to identify vulnerabilities. Identified critical vulnerabilities are remediated timely. Remediation status is monitored and non-compliance is escalated. Cyber Security Patch and System vulnerabilities A patch management program In-scope Vulnerability are mitigated through exists to incorporate, test, and Management patches. implement firmware updates and patches in a timely fashion Cyber Security Threat Detection Logging mechanisms and Logging mechanisms are In-scope the ability to track configured to enable the activity is established, monitoring, analysis, tracked, and monitored. investigation, and reporting of unlawful, unauthorized, or inappropriate information system activity: The following events are tracked: General user access and activities Root access and activities Access to audit logs Invalid access attempts Changes to identification and authentication mechanisms Changes to or elevation of privilege access rights Initialization, stopping, or pausing of the audit logs Creation and deletion of system- level objects exceptions system faults information security events system/network events For each event, the following details are captured: Type of event Time Where the event occurred Source of the event Outcome of the event (success/failure) Unique identity of individuals associated with the event Identity or name of affected data, system component, or resource. Cyber Security Threat Detection Risk-based monitoring to Risk based monitoring is In-scope detect unauthorized performed using automated tools connections, devices, (e.g., SIEM tools) to detect events, and network unauthorized connections, services. devices, events, and network services. Automated tools are used to perform analysis of events. Monitoring is performed in compliance with legal and regulatory requirements. Events are analyzed to understand attack targets and methods. Cyber Security Threat Detection Automated mechanisms The organization employs In-scope communicate security automated mechanisms to make alert and advisory security alert and advisory information following information available throughout indicators of the organization when indicators compromise. of compromise are found. Cyber Security Threat Response Incident response A formal security incident In-scope program is in place to response program is established provide timely and to respond, report, escalate and effective response to user treat breaches and reported requests and resolution to security events or incidents. A all types of incidents. comprehensive incident response plan exists to identify, manage, respond to, and recover from security (e.g., system breach) and IT operational (e.g., process errors) incidents and is communicated to appropriate stakeholders. The incident response plan is reviewed and modified on a periodic basis. Cyber Security Threat Response Incident response The organization develops, In-scope program is in place to documents, and disseminate an provide timely and incident response policy. The effective response to user policies and procedures are requests and resolution to reviewed and updated, at a all types of incidents. minimum, on an annual basis. Cyber Security Threat Response Security incidents are Incident alert thresholds have In-scope contained and mitigated been established and all incident to prevent additional detection tools have been impact to business calibrated with the thresholds. operations and loss of Incidents (operational or IT information. security) are identified, logged, documented, reported to different levels within the organization, and tracked to closure. Cyber Security Programming Organizations should The organization establishes and In-scope Security establish and appropriately protects secure appropriately protect development environments for secure development system development and environments for system integration efforts that cover the development and entire system development integration efforts that lifecycle. cover the entire system development lifecycle. Cyber Security Programming Systems are developed An established system In-scope Security securely. development lifecycle (SDLC) process and methodology is in place, documented, maintained, and applied for system and software design, acquisition, implementation, configuration, integration, testing, modification, and maintenance. The process also specifies the tools to be used for system development. The secure SDLC process, methodology, and tools are reviewed on a periodic basis. Cyber Security Programming Systems are developed The SDLC process is inclusive of In-scope Security securely. information security considerations. Security roles and responsibilities during the development lifecycle have been defined. Organization's information security team and the risk management methodology is appropriately integrated into the SDLC process. Cyber Security Programming Systems are developed The Security team coordinates In-scope Security securely. with the system developers to define and develop system security plans. System security plans that outline the security requirements are documented and maintained for information systems. The plans are communicated to relevant and authorized internal and external users. Cyber Security Programming Test data should be Test data shall be selected In-scope Security selected carefully, carefully, protected and protected and controlled. controlled. Operational data is protected when used for test purposes. Test data and accounts are removed from system components before the system becomes active/goes into production. Cyber Security Programming Applications should be Developers employ secure coding In-scope Security developed using secure guidelines to software and mobile coding guidelines, in applications. Developers are order to address common trained at least annually in up-to- coding vulnerabilities. date secure coding techniques, including how to avoid common coding vulnerabilities. (Refer the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.) Cyber Security Programming Production data are not Production data are not used for In-scope Security used for testing or testing or development. development.

TABLE 7 Risk Test Type (TBD - As Category Domain Test Procedure (#) per engagement) Request List (#) Cyber Cloud Security 1. Obtain and review contracts with cloud Inquiry, Inspection, 1. Contracts with Security service providers to determine whether contracts and/or observation cloud service include information security provisions to providers. protect against cybersecurity and data security/data privacy risks. Cyber Cloud Security 1. Inquire with the control owner and determine Inquiry, Inspection, 1. Policies and Security if all relevant information security requirements and/or observation procedures related to are established and agreed with each supplier/ contracts between the vendor that may access, process, store, organization and communicate, or provide IT infrastructure suppliers/vendors. components for, the organization's information. 2. Evidence of 2. Inspect a sample of agreements and validate agreements between that they include the following: the organization and Roles and responsibilities suppliers/vendors. Service definitions and SLAs 3. Population - Information security controls to be System generated list implemented of contract System functions, ports, protocols, and other amendments during services required for the use of such services. the audit period. Requirement to provide notification of changes 2. Evidence that a new to services or controls customer or vendor Requirement to provide notification of 3rd contract addendum or party personnel transfers and terminations new vendor contract Laws and regulations that the third party needs was signed for a to comply with sample of changes to Penalties or claw back clauses confidentiality Locations that they can provide services out of commitments Limitations on data storage locations requiring customer or Incident management procedures vendor notification. Breach notification Right to audit Limitations and constraints of access Termination conditions Data disposal/return upon termination Ownership of products after development Quality requirements Security training requirements for employees Business-critical or customer-impacting application design, development, and deployment Business-critical or customer-impacting system designs and configurations design, development, and deployment Business-critical or customer-impacting infrastructure network and system components design, development, and deployment IT Governance and service management policies and procedures Customer requirements policies and procedures for service-to-service application Customer requirements policies and procedures for information processing, interoperability, and portability for application development Customer requirements policies and procedures for information exchange, usage, and integrity persistence 3. Inquire with the control owner to determine if confidentiality commitments with vendors/ suppliers are changed during the normal course of business. If changes to confidentiality commitments are required, verify through inquiry with the control owner that a vendor contract addendum or new vendor contract is established. 4. Obtain the population of tickets related changes to confidentiality commitments requiring vendor/supplier notification. 5. For a sample from the above #4 population, verify that a vendor contract addendum or new vendor contract was signed. Cyber Cloud Security 1. Inquire with the control owners and observe Inquiry, Inspection, 1. System and Security the organization's processes for defining the and/or observation services acquisition safeguards that protect systems against supply policies and chain threats, as well as the automated procedures. mechanisms supporting supply chain threat 2. Procedures for the safeguards. Determine if the organization integration of security protects its information systems, system requirements into the components, or information system services development process. from supply chain threats by implementing 3. Service delivery security safeguards as defined by the information agreements security strategy. 2. Inspect system and services acquisition policies and procedures, procedures for the integration of security requirements into the development process, and supporting documentation to determine the following: if the organization defines the security safeguards to implement as protection to information systems, system components, or system services against supply chain threats. if the organization assures reasonable information security across their information supply chain by performing annual reviews, including reviews of all partners and third-party providers that the organization's information supply chain depends on. 3. Inspect service delivery agreements and determine the following: that third party service providers are required to demonstrate compliance with information security and confidentiality, access control, service definitions, and delivery-level agreements defined. that third-party reports, records, and services shall undergo audit and review at least annually to govern and maintain compliance with the service delivery agreements. Cyber Cloud Security 1. Inquire with the control owner and determine Inquiry, Inspection, 1. Cloud service Security the following: and/or observation policies and The organization uses secure standardized procedures network protocols (e.g., non-clear text and authenticated) to manage services. The organization makes available to customers documentation detailing relevant interoperability and portability standards. If the organization, as a cloud service provider, uses an industry-recognized virtualization platform and standard virtualization format to help ensure interoperability. if any custom changes made to any hypervisor in use and to all solution-specific virtualization hooks are documented and made available to customers for review. 2. Inspect cloud service security policies and procedures and determine the following: The organization uses secure standardized network protocols (e.g., non-clear text and authenticated) to manage services. The organization makes available to customers documentation detailing relevant interoperability and portability standards The industry-recognized virtualization platforms and standard virtualization formats are used to help ensure interoperability. The custom changes made to any hypervisor in use and to all solution-specific virtualization hooks shall be documented and made available to customers for review. Cyber Cloud Security 1. Determine through inquiry with control owner Inquiry, Inspection, Security whether processes are in place to remove any and/or observation previous content from shared resources when it is being allocated for reuse to new set of users. Cyber Data Security 1. Confirm the following have been addressed Inquiry, Inspection, Security within policies and procedures for the use of and/or observation electronic communication facilities: procedures designed to protect exchanged information from interception, copying, modification, incorrect routing, and destruction procedures for the detection of and protection against malicious code that may be transmitted through the use of electronic communications procedures for protecting communicated sensitive electronic information that is in the form of an attachment, policy or guidelines outlining acceptable use of electronic communication facilities procedures for the use of wireless communications, employee, contractor and any other users' responsibilities not to compromise the organization, use of cryptographic techniques, retention and disposal guidelines for all business correspondence in accordance with relevant national and local legislation and regulations, not leaving sensitive or critical information on printing facilities controls and restrictions associated with the forwarding of communication facilities, not leaving messages containing sensitive information on answering machines, reminding personnel not to register demographic data in any software to avoid collection for unauthorized use. Cyber Data Security 1. Inquire with the control owner to determine Inquiry, Inspection, 1. Data Classification Security whether the business value of each information and/or observation Policy and asset has been established and documented. procedures. 2. Inquire with the control owner and obtain the 2. Evidence that Data Classification Guide to determine if critical assets have classification schemes and procedures for been identified and handling, processing, storing and communicating documented. information consistent with its classification, 3. Evidence that the criticality, and business value are documented. security categorization 3. Inquire with the control owner to determine decision is reviewed whether critical assets have been identified and and approved by the documented. authorizing official or 4. Determine whether logical and physical authorizing official protection levels offered for data stored in designated databases, removable media, etc. is in alignment representative. with the classification level of the data. 4. Sample of media to 5. Inspect if the security classification decision is determine whether reviewed and approved by an authorizing official they have been or authorizing official designated representative. classified so that 6. Inspect if all media has been classified so that sensitivity of the data the sensitivity of the data can be determined. can be determined. 7. Validate whether all assets have been assigned 5. Evidence that assets an owner. are assigned to an owner. Cyber Data Security 1. Obtain and inspect relevant documents to Inquiry, Inspection, 1. Account Security determine if the organization implements various and/or observation Management data mining protection program for the Procedures. information system, system component, or 2. Information information system service. Security technical For example: standard. limiting the types of responses provided to 3. Access database queries; Management limiting the number/frequency of database procedures. queries to increase the work factor needed to 4. Database access determine the contents of such databases; and management notifying organizational personnel when procedures. atypical database queries or accesses occur. 2. Inquire with control owners to determine that established policies and procedures are in place and define data mining prevention and detection techniques, define that data storage objects are to be protected, and define the organization-defined techniques for data mining prevention and detection techniques for data storage 3. Inspect the organizations Account Management Procedures, Information Security Technical Standard, Access Management Procedures, Database Access Management Procedure, and determine that the established policies and procedures outline and define data mining prevention and detection techniques and storage protection: Cyber Data Security 1. Obtain and inspect relevant documents to Inquiry, Inspection, 1. Relevant policies Security determine if the organization aligns with its risk and/or observation and procedures. strategy and risk appetite when implementing 2. Evidence of review data protection measures. (e.g., sign 2. Inquire with control owners to determine that off/approvals policies and procedures are in place that documented in policy prescribe data protection measures based on revisions history). information classification and risk ranking. 3. Screenshot of the location of policies and procedures showing that they are available to company personnel. 4. Evidence showing that policies are part of annual security awareness. Cyber Data Security 1. Inquire with the control owner and determine Inquiry, Inspection, 1. Relevant policies Security if information security policies and procedures and/or observation and procedures. are documented, available and communicated to 2. Evidence of review personnel on accessible resources (internal (e.g., sign network, shared drive, etc.). off/approvals 2. Inspect policies and procedures to confirm if documented in policy they are reviewed/updated at least annually or revisions history). more frequently if required based on changes in 3. Screenshot of the the environment. location of policies 3. Security policies and operational procedures and procedures should address organization-determined areas showing that they are and best practices, examples include: available to company Business Continuity/Disaster Recovery; personnel. Data Protection/DLP; 4. Evidence showing Access Management; that policies are part Vendor Management; of annual security Physical Security; awareness. SDLC; Security Awareness training; Mobile device management; Legal/regulatory requirements; System/service acquisition; User agreements. Incident Management Network Security Configuration Management Application Security Cryptography and Key Lifecycle Management Risk Assessment and Treatment Data confidentiality, integrity and availability across multiple system interfaces, jurisdictions, business functions Cyber Data Privacy 1. Inquire of management and obtain evidence to Inquiry, Inspection, Special Note: Security validate whether the organization has capabilities and/or observation Personally identifiable to prevent or monitor data leaks. information (““PII””) 2. Determine if the organization performs and Protected Health activities to analyze potential opportunities for Information (““PHI””) covert channels. If so, determine if testing is fall under ““Customer performed to identify exploitable channels and Data”” and is thus the bandwidth associated with those channels. subjected to the 3. Inquire with the control owner to determine if company's data the above-mentioned capabilities in test classification schema procedure #1 are aligned with legislative, and controls. regulatory, or contractual obligations, 1. Data Classification 4. Obtain and inspect policies, procedures, and and Protection other supporting documentation to validate policies and whether the aforementioned capabilities in test procedures. procedure #1 are in place to enable the 2. Policies and organization to meet their obligations to procedures related to customers in accordance with contractual Data Loss Prevention requirements. and the handling of customer data. 3. Evidence of the organizations capabilities to prevent or monitor data leaks. 4. Evidence that data loss prevention processes and procedures are aligned with legislative, regulatory, or contractual obligations. Cyber Data Privacy [General Privacy Requirements; Notice, Choice, Inquiry, Inspection, 1. Privacy policies Security Consent] and/or observation and procedures 1. Inquire with the control owner and determine regarding where information security policies and confidentiality and procedures are documented and available to non-disclosures. personnel with access to PII on accessible 2. ISMS manual resources (internal network, shared drive, etc.). (Executive 2. Review policies and procedures to confirm Leadership, CTO) they are reviewed/updated at least annually or 3. Evidence to more frequently if required based on changes in demonstrate that the environment, documents are 3. Inspect the information security policies on available to personnel the company's internal network and determine with access to PII on they are available and communicated to accessible resources company personnel with access to PII and such as internal include security roles, responsibilities, and network, shared drive, procedures. Specifically, privacy policies and etc. operational procedures for the confidentiality 4. Data localization and non-disclosure agreements. policy [Storage Location of PII] 5. List of countries 1. Inquire with the control owner and determine that might have access that the organization has documented data to the organization's localization policies and procedures available to customers' PII. personnel on accessible resources (company 6. Evidence intranet, shared drive). documenting the 2. Inspect the data localization policy on the review and update company's internal network and determine they procedures performed are available and communicated to company by the organization to personnel and address that the organization ensure that the list of documents and makes available the countries countries is accurate where PII might be stored as required. and up to date. 3. Inspect policies and procedures to confirm they are reviewed and updated based on changes in the environment. 4. Obtain and inspect the list of countries that might have access to the organization's customers' PII. 5. Obtain and inspect the list of countries to determine the review and update procedures performed by the organization to ensure that the listing is accurate and up to date. Cyber Data Privacy 1. Inquire with control owners to understand Inquiry, Inspection, 1. Data privacy policy Security where, within the organization's data policies, and/or observation showing the the expectations for the return, transfer, and/or expectations for the destruction of PII is defined. In addition, return, transfer, and/or determine how this is communicated to the destruction of PII by customers (i.e. website, contract/amendments). the organization for 2. Obtain and observe the appropriate the customers. documentation (i.e. data policy) showing the 2. Data Classification expectations for the return, transfer, and/or policy for restricted destruction of PII by the organization for the class protection. customers. Cyber Penetration 1. Inquire with the control owner to determine Inquiry, Inspection, 1. Copy of most Security Testing whether penetration tests are performed on a and/or observation recent penetration test periodic basis and remediation plans are and penetration test developed to address the risks. methodology utilized. 2. Inspect the results of the most recent 2. Population of risks penetration test to determine whether it was from most recent completed within the organization-specified time penetration test. period and performed by an independent 3. For a sample of penetration agent or team. risks, please provide 3. Inspect ticket details and supporting ticket/supporting documentation for a sample of risks identified in details to document the most recent penetration test to determine remediation. whether the risks were remediated or were being 4. Please provide actively worked to remediation. evidence that both external and internal penetration tests are performed at least annually and after any significant infrastructure or application modification. Cyber Network 1. Inspect documented procedures and determine Inquiry, Inspection, 1. Firewall and router Security Security that there is a formal process for testing and and/or observation configuration approval of all: standards Network connections; and 2. Evidence of Changes to firewall and router configurations firewall rule review. 2. Obtain a population of changes to network 3. Router rule sets connections, firewalls, and router configurations. 4. Network diagrams 3. Select samples and obtain tickets. 5. Population of 4. Inspect tickets from selected sample to changes to network validate that changes to network connections, connections, firewalls, firewalls, and router configurations were tested and router and approved. configurations. 5. Validate whether the network diagrams are 6. Tickets for samples updated if there is a change in the network of changes to network connection. connections, firewalls, and router configurations. 7. Population of firewall reviews, from which a sample will be selected. 8. Evidence of firewall reviews for the sample selected. Cyber Patch and 1. Inquire with the control owner to determine if Inquiry, Inspection, 1. Policies and Security Vulnerability a formal vulnerability management program and/or observation procedures related to Management exists and tools are in place to detect, report, and vulnerability correct vulnerabilities. management. 2. Determine if there is a formally documented 2. Population of vulnerability management methodology and vulnerability/patch procedures. tickets. 3. Through interviews with the control owner, 3. Sample evidence of inspection of reports, determine whether system ticket resolution vulnerabilities are identified and tracked. including risk ranking. 4. Inspect tickets to determine if the vulnerability 4. Information was ranked, worked to resolution based on Security Policies and criticality, authorized, tested, and approved prior procedures. to implementation into production. 5. Verify whether the program is evaluated on a quarterly basis. Cyber Patch and 1. Inquire with the control owner and determine Inquiry, Inspection, 1. Evidence that Security Vulnerability if vulnerability scans were performed on both and/or observation vulnerability scans Management external and internal facing production systems were performed on using internal scanning resources on an both external and organization-defined frequency. internal facing 2. Inspect the internal scanning resource production systems configurations and determine vulnerability scans using internal were scheduled to run with an appropriate scanning resources. frequency and were configured to run against 2. Scanning resource internal and external IP ranges. configuration. 3. Inspect the vulnerability scan report for a 3. Reference of sample of weeks and determine an internal and internal IPs from a external vulnerability scan was completed in source that is accordance with the configured schedule. independent from the 4. Inspect if the organization performs privileged/ team responsible for authenticated vulnerability scans vulnerability scanning 5. Inspect if the organization employs 4. Internal and vulnerability scanning procedures that can external vulnerability identify the breadth and depth of coverage (i.e., scan reports for the information system components scanned and for the selected weeks vulnerabilities checked). (to be specified). 6. Inspect if the organization employs vulnerability scanning procedures that updates the information system vulnerabilities scanned. Cyber Patch and 1. Determine the number of vulnerabilities Inquiry, Inspection, 1. Obtain a listing of Security Vulnerability identified. and/or observation application systems Management 2. Validate that patch management process is with vulnerabilities. initiated to address the known vulnerabilities. 2. Obtain a listing of 3. Validate that patch is tested and applied timely patches deployed to to mitigate the known vulnerabilities. address identified vulnerabilities in a timely manner. 3. Obtain evidence showing that the patches were tested before deployed into production Cyber Threat 1. Inquire with the control owners and inspect Inquiry, Inspection, 1. System generated Security Detection evidence to validate whether or not the and/or observation list of production organization performs logging related to both servers and network unauthorized actions and access. The following devices as of present items are examples of logging mechanisms that day with source, filter/ should be in place: query details, etc. Action-related logging events: 2. Log configurations all changes, additions, or deletions to any for a sample of account with root or administrative privileges; production servers Initialization, stopping, or pausing of audit and network devices. logs; 3. Evidence that the creation and deletion of system level objects; organization performs creation, modification, enabling, disabling, and logging related to both removing of accounts; unauthorized actions initialization and the stopping or pausing of and access. audit logs. 4. Policies and system security configuration changes procedures related to activation and de-activation of protection access control, systems (e.g., A/V and IDS) account management, management activities, system and application audit and startup/shutdown/errors, file changes, and accountability, storage security policy changes. engineering, and audit Access-related logging events: record content. successful and unsuccessful account logon 5. Evidence that the events; organization all individual access to cardholder data; configures access to all audit trails; information systems elevation of privileges. to allocate storage 2. Inquire of management and inspect evidence space for the retention to validate whether the organization: of audit records. includes user identification, event type, date and time stamp, indication of success or failure, event origination, and identity of affected data, system component, or resources in log entries; monitors information system accounts for abnormal usage and activity; reports abnormal usage and activity on information system accounts to specified personnel; configures information systems to generate audit records that contain information on what type of event occurred, when and where the event occurred, the source and outcome of the event, and the identity of individuals associated with the event; continuously writes logs from production servers, network devices, databases and storage management hosts to system logs and forwards them to the logging and alerting system in real- time in order to provide backup media for records other than the audited system; configures the information system to provide the capability to generate audit records for defined auditable events for specified information system components; configures the information system to allow specified personnel to select which auditable events should be audited by specific system components; configures the information system to provide capabilities for specified individuals to change the performed audits on information system components based on defined selectable event criteria within specified thresholds. 3. Inspect policies and procedures around access control, account management, audit and accountability, storage engineering, and audit record content and validate whether or not the organization. defines abnormal information system account usage and the personnel to be notified upon the identification of abnormal system usage; configures the information system to generate audit records that contain information on what type of event occurred, when and where the event occurred, the source and outcome of the event, and the identity of individuals associated with the event; defines the additional detailed information required to be included in audit records that the information system generates; defines the information system components that provide audit record generating capabilities for defined auditable events; defines the personnel whom are allowed to select which auditable events are to be audited by specified information system components, and change the validating performed on specified information system components; defines the information system components that validating is performed on; defines the time thresholds that must be met for specified individuals to change the audit functions performed on information system components; defines the event criteria that can be selected by specified individuals or roles to support the capabilities of changing audit functions performed on information system components; continuously writes logs from production servers, network devices, databases and storage management hosts to system logs and forwards them to the logging and alerting system in real- time in order to provide backup media for records other than the audited system 4. Inspect audit record storage capacity related to information system configuration settings and determine that the organization configures information systems to allocate storage space for the retention of audit records and that it is sufficient in accordance to defined requirements. Cyber Threat 1. Inquire with the control owner to determine if Inquiry, Inspection, 1. Evidence that the Security Detection documented procedures for monitoring are in and/or observation organization monitors place to detect vulnerabilities, indicators of the Blockchain potential attacks in accordance with information system to (organization-defined) monitoring objectives, detect unauthorized/ unauthorized local, network, and remote malicious activity. connections; 2. Provide a list of 2. Inquire with the control owner to verify tools and processes in whether monitoring tools are implemented in place to monitor the high risk systems and environments to detect Blockchain anomalous events and activities: information system Inbound and outbound communications and their Internal system activities, including configurations. unauthorized system use and transactions 3. Provide a system Unauthorized connections generated list of Unauthorized users vulnerability tickets Unauthorized devices for the period under Unauthorized software review, from which a Unauthorized remote access connections sample will be 3. Verify whether action is taken as part of selected. incident response and vulnerability management 4. Provide the internal plan when anomalous events are detected tickets from the 4. Inspect the monitoring tools to verify their selected sample. configuration and validate whether they are configured to detect anomalous events. Cyber Threat 1. Inquire with management to determine if the Inquiry, Inspection, 1. Information Security Detection organization employs automated mechanisms to and/or observation security policies and make security alert and advisory information procedures related to available throughout the organization. security alerts and 2. Inspection information security policies to advisories. determine if the organization has defined 2. Evidence of requirements regarding automated mechanisms processes in place for to make security alert and advisory information defining, receiving, available throughout the organization. generating, and 3. Inspect organizational processes in place for disseminating security defining, receiving, generating, and alerts and advisories. disseminating security alerts and advisories, including automated mechanisms supporting and/or implementing dissemination of security alerts and advisories. Cyber Threat 1. Verify that a formal incident response Inquiry, Inspection, 1. Information Security Response program exists and includes formally defined and/or observation Security Incident roles and responsibilities, an incident response Management plan, and resources to support incident response. documentation 2. Obtain the copy of the incident response plan. 2. CSIRT/Incident Verify that it is formally documented and has Response Plan been approved by a senior Management 3. CSIRT/Incident executive. Response Process 3. Validate that the incident response plan 4. Provide document has been recently (within the last year) documentation for reviewed and the latest plan has been shared with previously reported and communicated to personnel with incident incidents or alerts. response responsibilities. 4. Verify whether the incident response plans covers both IT operational and security incidents. 5. Verify that the incident response plan contains the following: Roles and responsibilities, and structure and organization of the incident response capability; Incident response process flows and procedures that include steps for preparation, detection and analysis, containment, eradication, and recovery; Defines reportable incidents and incident classification; Incident communication and notification; Analysis of legal requirements for reporting compromises; Provides metrics for measuring the incident response capability within the organization; Defines the resources and management support needed to effectively maintain and mature an incident response capability; System and data recovery; Data backup processes. 6. Verify if the incident response plan is periodically updated to address system/organizational changes or problems encountered or lessons learned during plan implementation, execution, training, or testing. 7. Review documentation from a sample of previously reported incidents or alerts to verify that the documented incident response plan and procedures were followed. Cyber Threat 1. Inquire with control owner to determine if the Inquiry, Inspection, 1. CSIRT Incident Security Response organization develops, documents, and and/or observation Response Plan disseminate an incident response policy. 2. Security Incident 2. Examine the incident response plan to Response Process determine if an incident response policy exists 3. Corporate Critical and whether the policy address the specific Incident Process purpose, scope, roles and responsibilities, 4. Information management commitment, and compliance. Security Policies 3. Examine the information security policies and 5. Crisis Management procedures (see evidence), CSIRT Incident Team Plan Response Plan, Security Incident Response Process, Corporate Critical Incident Process and determine if the incident response procedures are disseminated to appropriate personnel. 4. Observe location of incident response plan on the organization intranet (or other location) to determine how the incident response policies are disseminated. 5. Examine the incident response plan to determine if the organization has reviewed and updated on an annual basis. Cyber Threat 1. Inquired of the control owner to determine Inquiry, Inspection, 1. Listing of recent Security Response whether security incidents were tracked and and/or observation incidents for the documented from initiation through closure. period under review 2. Obtain a listing of incidents for the period and parameters/query under review and select an appropriate number used to generate the of samples. report. 3. Obtain tickets or documentation to validate 2. Documentation of that the incidents were documented incident containment (categorized/prioritized), reviewed, tracked and and mitigation, such resolved in a timely manner and includes the as IT tickets. following details: The identified solutions or workaround are documented, applied and tested, and recovery actions are performed to restore the IT-related service. The satisfactory resolution of incidents and/or request fulfillment is verified and is closed. 4. Determine whether incident thresholds have been established and whether the tools have been calibrated with the thresholds. Cyber Programming 1. Inquire with the control owner to determine Inquiry, Inspection, 1. Information Security Security whether the organization establishes guidelines and/or observation Security Policies for the secure development environment for containing technical critical systems. roles that address 2. Inspect the information security policies to development determine whether the policies outline guidance activities, and for technical roles and secure development established guidelines environment for critical systems. for the secure 3. Validate whether management reviewed the development policy within the past 12 months and environment for communicated it to employees. critical systems. 4. Review the secure development standards to 2. Evidence that validate whether appropriate measures have been management reviewed described for security of development the Information environments. Security Policies 5. Review the access list for a sample of within the past 12 development environments and validate whether months and the access has been approved. Also validate communicated it to whether any non-developers have access to the employees. development environment. Cyber Programming 1. Inquire with control owner to whether an Inquiry, Inspection, 1. SDLC policies and Security Security established system development lifecycle and/or observation procedures. process is in place, documented, maintained, and 2. Evidence that an applied for all system and software design, established system acquisition, implementation, configuration, development lifecycle integration, testing, modification, and process is in place, maintenance. documented, 2. Obtain and inspect SDLC policies and maintained. procedures to determine whether an established 3. Security system development lifecycle process is requirements for documented. information systems 3. Verify whether security requirements for and information information systems and information services are services are identified identified as part of SDLC efforts, business process re-design, etc. Cyber Programming 1. Obtain the SDLC process/methodology Inquiry, Inspection, 1. Policy for the Security Security documentation and verify whether it specifies and/or observation SDLC process that the developers should consider information 2. System and security during the requirements gathering, high Services Acquisition level design, low level design, development, and Policies, Procedures systems integration phases of developing an and Standards information system. 3. Information 2. Verify whether the SDLC Security Procedures process/methodology documentation specifies (SDLC process) whether the testing phase should include security testing of information systems. 3. Verify that during the functional requirements gathering phase, the information security requirements are captured and consider the following: the level of confidence required towards the claimed identity of users, in order to derive user authentication requirements access provisioning and authorization processes required protection needs of assets involved requirements derived from business processes, such as transaction logging and monitoring, non- repudiation requirements requirements mandated by other security controls, e.g., interfaces to logging and monitoring or data leakage detection systems information users and operators of their duties and responsibilities 4. Verify whether the SDLC process/methodology defines the security roles and responsibilities during the development lifecycle. 5. Verify whether there is a clear integration between the organization risk management methodology and SDLC methodology and whether it outlines how information systems can be classified based on their inherent risk. Cyber Programming 1. Inspect if the organization: Inquiry, Inspection, 1. Security program Security Security Develops a security plan for the information and/or observation plans, budget, system that: procedures, and Is consistent with the organization's enterprise policies architecture 2. Information Explicitly defines the authorization boundary Security Governance for the system; Program Describes the operational context of the documentation information system in terms of missions and business processes; Provides the security categorization of the information system including supporting rationale; Describes the operational environment for the information system and relationships with or connections to other information systems; Provides an overview of the security requirements for the system; Identifies any relevant overlays, if applicable; Describes the security controls in place or planned for meeting those requirements including a rationale for the tailoring decisions; and Is reviewed and approved by the authorizing official or designated representative prior to plan implementation; Distributes copies of the security plan and communicates subsequent changes to the plan to organization-defined personnel or roles; Reviews the security plan for the information system per organization-defined frequency; Updates the plan to address changes to the information system/environment of operation or problems identified during plan implementation or security control assessments; and Protects the security plan from unauthorized disclosure and modification. 2. Inspect if the organization. Identifies organization-defined user actions that can be performed on the information system without identification or authentication consistent with organizational missions/business functions; and Documents and provides supporting rationale in the security plan for the information system, user actions not requiring identification or authentication. Cyber Programming 1. Inquire with control owner/interview Inquiry, Inspection, 1. Provide written Security Security responsible personnel to understand how and/or observation software-development production data is sanitized, transferred, and procedures. used for test purposes. 2. Provide a 2. Obtain and inspect written software- population of project development procedures to verify that plans/checklists, from operational data is sanitized, transferred, when which a sample will used for test purposes. be selected. 3. Observe testing processes and interview 3. Provide the project personnel to verify operational data is protected plans and checklists through testing. for the sample 4. Obtain a population of project plans/checklists selected. for the period under review. [PCI] 5. Select a sample of project plans and checklists 1. Provide a to determine whether data protection activities population of data and are built into the overall test approach. accounts from production systems recently installed or updated for the period under review, from which a sample will be selected. 2. Provide supporting evidence for the selected sample of data and accounts from production systems. Cyber Programming 1. Inquire with the control owner to determine Inquiry, Inspection, 1. Secure Coding Security Security the following: and/or observation Guidelines; that documented software and mobile secure Infrastructure coding guidelines are available to outline Hardening Guidelines development and implementation guidance for and Secure Coding software and mobile code Guidelines. that the organization authorizes, monitors, and 2. System and controls mobile code use within the information Communications system Protection Policies 2. Inspect the Secure Coding Guidelines and and procedures determine that acceptable and unacceptable software and mobile coding guidelines along with implementation guidance are outlined within the documents, including: a. Secure coding techniques training is required for developers at least annually, based on industry best practices and guidance; b. Software-development process procedures: defines software-development processes based on industry standards and leading practices defines information security throughout the software development lifecycle defines that developers must develop software applications in accordance with standards determine that the software-development standards are implemented. c. Injection flaws: Validate inputs to determine that user data cannot modify meaning of commands and queries. Utilizing parameterized queries. d. Buffer overflows: Validate buffer boundaries. Truncating input strings. e. Insecure cryptographic storage Prevent cryptographic flaws. Use strong cryptographic algorithms and keys. f. Insecure communication Determine that insecure communications are addressed by coding techniques that properly authenticate and encrypt all sensitive communications. g. Improper error handling Validate that improper error handling is addressed by coding techniques that do not leak information via error messages h. All “high risk” vulnerabilities identified in the vulnerability identification process Verify that coding techniques address any “high risk” vulnerabilities that could affect the application i. Cross-site scripting (XSS) Validating all parameters before inclusion Utilizing context-sensitive escaping j. Improper Access Control Proper authentication of users Sanitizing input Not exposing internal object references to users User interfaces that do not permit access to unauthorized functions. k. Cross-site request forgery (CSRF) to determine that cross-site request forgery (CSRF) is addressed by coding techniques that ensure applications do not rely on authorization credentials and tokens automatically submitted by browsers. 1. Broken authentication and session management: Flagging session tokens (for example cookies) as “secure” Not exposing session IDs in the URL Incorporating appropriate time-outs and rotation of session IDs after a successful login. 3. Inspect system and communications protection policy and procedures addressing mobile code and determine the following: that the organization defines the mobile code and mobile code technologies that are acceptable and unacceptable; that the organization establishes restrictions for acceptable mobile code and mobile code technology use; that the organization documents implementation guidance for the defined acceptable mobile code and code technologies. 4. Observe the organization's defined processes for controlling, authorizing, monitoring, and restricting mobile code and determine that the organization authorizes, monitors, and controls mobile code use within the information system. Cyber Programming 1. Inquire with the control owners and determine Inquiry, Inspection, 1. Policies and Security Security if procedures clearly define that production data and/or observation procedures related to (live PANs) are not used for testing or production data (live development. PANs). 2. Observe the testing processes and determine 2. Population of data that the organization's personnel do not use and accounts from production data (live PANs) in testing or in recently installed or development. updated production 3. Obtain a population of data and accounts from systems. recently installed or updated production systems. 3. Sample of test data 4. Select a sample of data and accounts and and accounts from the inspect test data to determine whether production obtained population. data (live PANs) are used for testing or development.

In some embodiments, infrastructure layer risk category in the blockchain risk framework covers relevant risks, control objectives and descriptions, testing objectives and procedures, and reporting parameters designed to address assurance and compliance needs for the blockchain infrastructure stack/layer supporting functioning of the underlying hardware, software, servers, databases, networks, interfaces technologies (e.g. APIs etc.).

The sub-risk categories, control and testing objectives, test procedures and request lists for Infrastructure Layer risk category are provided below in Tables 8-10.

TABLE 8 Risk Level (L, Risk Risk M, H) (As Risk Category Domain Classification Number Risk Description applicable) Infrastructure Layer Servers and Strategic, IL-SD1 Lack of guidance and policy of L, M, H Databases Operational, functional requirements and Configuration Financial, migration to production may lead Compliance, to inaccurate Blockchain logic. Legal, or Reputational Infrastructure Layer Servers and Strategic, IL-SD2 Lack of an established baseline L, M, H Databases Operational, for information technology Configuration Financial, systems and Blockchain may Compliance, affect operational environments Legal, or and compromise security. Reputational Infrastructure Layer ITGCs Strategic, IL-IT1 Unauthorized or untested L, M, H Operational, changes, or the failure to make Financial, necessary changes to operating Compliance, system, network or application Legal, or configurations or programs Reputational prevent systems from processing transaction records completely and accurately Infrastructure Layer ITGCs Strategic, IL-IT2 Lack of segregation for roles L, M, H Operational, and responsibilities and instance Financial, environments may lead to Compliance, unauthorized changes to Legal, or productions. Reputational Infrastructure Layer ITGCs Strategic, IL-IT3 Lack of segregation for roles L, M, H Operational, and responsibilities and instance Financial, environments may lead to Compliance, unauthorized changes to Legal or productions. Reputational Infrastructure Layer ITGCs Strategic, IL-IT4 Transaction records are lost L, M, H Operational, (e.g. due to system failure) Financial, and data is not recoverable or Compliance, is corrupted/duplicated in the Legal, or recovery process Reputational Infrastructure Layer ITGCs Strategic, IL-IT5 Transaction records transferred L, M, H Operational, between systems are incomplete Financial, or inaccurate. Compliance, Legal, or Reputational Infrastructure Layer ITGCs Strategic, IL-IT6 As business processes are L, M, H Operational, redesigned and modified to reflect Financial, use of Blockchain technology, Compliance, they embed an agreed set of Legal, or appropriate controls Reputational Infrastructure Layer ITGCs Strategic, IL-IT7 Application end-users bypass L, M, H Operational, systems-enforced authorization Financial, and segregation of duties controls Compliance, Legal, or Reputational Infrastructure Layer ITGCs Strategic, IL-IT8 Application end-users bypass L, M, H Operational, systems-enforced authorization Financial, and segregation of duties controls Compliance, Legal, or Reputational Infrastructure Layer ITGCs Strategic, IL-IT9 High-risk/powerful accounts L, M, H Operational, (e.g., super-user, etc.) bypass Financial, systems-enforced authorization Compliance, and segregation of duties Legal, or controls Reputational Infrastructure Layer ITGCs Strategic, IL-IT10 Unauthorized access to facilities, L, M, H Operational, equipment and resources is not Financial, prevented Compliance, Legal, or Reputational Infrastructure Layer ITGCs Strategic, IL-IT11 Unauthorized access (by L, M, H Operational, business users, IT users or Financial, outsiders) to data causes data Compliance, destruction or improper Legal, or amendment of records. Reputational Infrastructure Layer ITGCs Strategic, IL-IT12 Unauthorized access (by L, M, H Operational, business users, IT users or Financial, outsiders) to data causes data Compliance, destruction or improper Legal, or amendment of records. Reputational Infrastructure Layer ITGCs Strategic, IL-IT13 Duties are not appropriately L, M, H Operational, segregated Financial, Compliance, Legal, or Reputational Infrastructure Layer ITGCs Strategic, IL-IT14 Weak password controls or L, M, H Operational, security configurations allow Financial, access rights to be circumvented Compliance, Legal, or Reputational Infrastructure Layer ITGCs Strategic, IL-IT15 Unauthorized access (by L, M, H Operational, business users, IT Financial, users or outsiders) to Compliance, Blockchain Operational Legal, or governance tools. Reputational Infrastructure Layer ITGCs Strategic, IL-IT16 Unauthorized or untested L, M, H Operational, changes, or failure to make Financial, necessary changes to scheduled Compliance, job processes prevent systems Legal, or from processing transaction Reputational records completely and accurately Infrastructure Layer ITGCs Strategic, IL-IT17 Unauthorized or untested L, M, H Operational, changes, or failure to make Financial, necessary changes to scheduled Compliance, job processes prevent systems Legal, or from processing transaction Reputational records completely and accurately Infrastructure Layer ITGCs Strategic, IL-IT18 Blockchain processing errors L, M, H Operational, are not resolved. Financial, Compliance, Legal, or Reputational Infrastructure Layer ITGCs Strategic, IL-IT19 Unauthorized access to the L, M, H Operational, Blockchain technology (i.e. Financial, code configuration tools) is Compliance, prevented. Legal, or Reputational Infrastructure Layer ITGCs Strategic, IL-IT20 Management release L, M, H Operational, management policies and Financial, procedures include processes Compliance, for making emergency Legal, or configuration changes, including Reputational formal review processes for all changes categorized as emergency. Infrastructure Layer ITGCs Strategic, IL-IT21 Unauthorized or untested L, M, H Operational, changes, or failure to make Financial, necessary changes to scheduled Compliance, job processes prevent systems Legal, or from processing transaction Reputational records completely and accurately Infrastructure Layer Business Strategic, IL-BC1 A lack of backups or ineffective L, M, H Continuity and Operational, backups may lead to information Disaster Financial, loss. Recovery Compliance, Legal, or Reputational Infrastructure Layer Business Strategic, IL-BC2 Lack of Business Continuity L, M, H Continuity and Operational, and Disaster Recovery plans Disaster Financial, may inhibit the organization's Recovery Compliance, ability to recover from an outage. Legal, or Reputational Infrastructure Layer Business Strategic, IL-BC3 A lack of backups or ineffective L, M, H Continuity and Operational, backups may lead to information Disaster Financial, loss. Recovery Compliance, Legal, or Reputational Infrastructure Layer Business Strategic, IL-BC4 Lack of Business Continuity L, M, H Continuity and Operational, and Disaster Recovery plans Disaster Financial, may inhibit the organization's Recovery Compliance, ability to recover from an Legal, or outage. Reputational Infrastructure Layer Business Strategic, IL-BC5 A lack of Business Continuity L, M, H Continuity and Operational, plan and Disaster Recovery plan Disaster Financial, testing may result in an effective Recovery Compliance, or failed recovery process. Legal, or Reputational Infrastructure Layer Business Strategic, IL-BC6 Lack of communication to key L, M, H Continuity and Operational, stakeholders regarding their Disaster Financial, responsibilities may result in Recovery Compliance, ineffective recovery activities in Legal, or the event of an outage. Reputational Infrastructure Layer IT Asset Strategic, IL-IT1 Without clearly defined roles L, M, H Management Operational, and responsibilities with Financial, Blockchain vendors, Compliance, accountability is lost when Legal, or issues arise within Reputational the relationship Infrastructure Layer IT Asset Strategic, IL-IT2 Without clearly defined roles L, M, H Management Operational, and responsibilities with Financial, Blockchain vendors, Compliance, accountability is lost when Legal, or issues arise within the Reputational relationship Infrastructure Layer IT Asset Strategic, IL-IT3 Without a comprehensive due L, M, H Management Operational, diligence process, vendor risks Financial, may not be completely identified, Compliance, leaving the organization Legal, or susceptible to direct and indirect Reputational risks. Infrastructure Layer IT Asset Strategic, IT-IL4 Without clearly defined roles L, M, H Management Operational, and responsibilities with Financial, Blockchain vendors, Compliance, accountability is lost when Legal, or issues arise within the Reputational relationship Infrastructure Layer IT Asset Strategic, IL-IT5 Lack of required level of L, M, H Management Operational, throughput and performance Financial, can compromise Blockchain Compliance, use cases objectives. Legal, or Reputational Infrastructure Layer IT Asset Strategic, IL-IF1 Data exchanged through APIs, L, M, F Management Operational, system interfaces may be Financial, intercepted and accessed by Compliance, unauthorized agents within or Legal, or outside the organization's Reputational network

TABLE 9 In-scope/Out- of-Scope (TBD-As per Risk Category Domain Control/Test Objective Control Description engagement) Infrastructure Servers and References to internal and external Once the Blockchain has been In-scope Layer Databases sources (including interaction with configured, a test plan is Configuration external platforms, systems, developed to ensure meeting networks, and third parties) in the all functional requirements Blockchain logic are accurate. and approved by the Blockchain program management. The Blockchain configurations are tested by the impacted/required business and/or the Blockchain program management team. Test exceptions are appropriately recorded, monitored and tracked for resolution prior to migration to production Infrastructure Servers and A baseline configuration of A configuration management In-scope Layer Databases information technology systems program and database exists Configuration and Blockchain is created, to implement, maintain and implemented, control configuration of and maintained systems and other infrastructure elements. Infrastructure ITGCs Change Management controls are Changes to Blockchain In-scope Layer defined, established, and enforced Application and Operating including proper documentation System/Network and approval configurations and enhancements are adequately tested and approved before being migrated into production and are monitored for appropriateness. Infrastructure ITGCs Segregation of Duties is maintained Access to migrate the In-scope Layer and enforced for any changes, in Blockchain process addition the development, test, and configurations into production production environments are is restricted to personnel who separated. are independent of the configuration team. Development, testing, and production environments are segregated for changes to application configurations and periodically reviewed to ensure access is restricted to authorized personnel. Infrastructure ITGCs Segregation of Duties is maintained Policies are maintained for In-scope Layer and enforced for any changes. segregation of duties within IT Infrastructure ITGCs Backups of information are Data is appropriately backed In-scope Layer conducted, maintained, and tested up and recoverable periodically. Infrastructure ITGCs Information input and output Errors in production In-scope Layer checks are performed. processing are identified and resolved Infrastructure ITGCs Change Management controls are For each new Blockchain In-scope Layer defined, established, and enforced business process the including proper documentation associated controls are and approval, documented and approved by the business and the Blockchain program management. Infrastructure ITGCs Access permissions are revoked Terminated employee's/third In-scope Layer based upon access reviews and/or party or employee's/third user terminations. party access no longer needed to Blockchain, database, and operating system/network is disabled and/or removed in a (timely manner). Infrastructure ITGCs Access to systems and assets is Access requests to the In-scope Layer controlled by incorporating the application, database, and principle of least privilege. operating system/network are properly reviewed and authorized by management Infrastructure ITGCs Privileged user roles and Super-user/administrative In-scope Layer responsibilities are managed and application, database, and tracked. operating system/network transactions or activities and sensitive generic IDs are monitored Infrastructure ITGCs Physical access controls are in place Employees', contractors', and In-scope Layer to properly authorize employees, visitors' access to data contractors, and visitors to facilities, center/facility and the equipment and resources, information system components located within the facility is provided on a ‘need to know’ basis and requires organizational approval. Infrastructure ITGCs Physical access to the secure areas There is physical security in In-scope Layer are monitored. place over the data center from which financially significant applications are run. Key card system is implemented in the data center for access control. And video surveillance is also in place to monitor the activities in the data center. The key card system logs the visit to the data center per user and ID card. If any incident happens, IT department will look into the system log and video footage for investigation. Infrastructure ITGCs Access permissions are reviewed Data Center Operations In-scope Layer periodically for appropriateness. performs a semi-annual recertification of all users with physical access to Data Centers Infrastructure ITGCs Segregation of Duties is maintained Policies and procedures are In-scope Layer and enforced for critical business maintained for segregation of processes and in production duties within IT environments. Infrastructure ITGCs Access to applications, database, Passwords to applications, In-scope Layer operating system and network is database/data file, operating password protected on a global system/network, and security level and complies with configurations are set in an documented policies or working effective manner practices detailing password configurations and configurable security parameters. Infrastructure ITGCs Access to the Blockchain Access to the Blockchain In-scope Layer Operational governance tools is operational governance tools restricted to appropriate personnel. is recertified by appropriate management at regular intervals as defined by policy guidelines. The approver confirms access remains commensurate with the individual's job responsibilities or requests changes/revocation to access. Infrastructure ITGCs As changes to the Blockchain are The Blockchain policies and In-scope Layer contemplated, appropriate controls procedures on change are in place to ensure that they are approval and propagation approved and rolled out across the across the network are defined network in a manner consistent and include a description of with the Blockchain governance key controls, oversight and framework. escalation procedures. Infrastructure ITGCs As changes to the Blockchain are Only approved and tested In-scope Layer contemplated, appropriate controls changes are made to the job are in place to ensure that they are scheduler and rolled out approved and rolled out across the across the network in a network in a manner consistent manner consistent with the with the Blockchain governance Blockchain governance framework. framework. Infrastructure ITGCs Formal policies and procedures The Blockchain management In-scope Layer have been established to identify has a documented problem the Blockchain processing errors. management process for the Blockchain configurations during which errors or exceptions are identified, tracked, escalated, root causes identified and resolved. Infrastructure ITGCs Access permissions are revoked Access to the Blockchain In-scope Layer based upon access reviews and/or configuration tools is user terminations, recertified by appropriate management at regular intervals as defined by policy guidelines. The approver confirms access remains commensurate with the individual's job responsibilities or requests changes/revocation to access. Infrastructure ITGCs Change Management controls are The formal policies and In-scope Layer defined, established and enforced procedures include detailed including proper documentation processes and required and approval approvals necessary to make an emergency change to the Blockchain configuration. A formal review is conducted for all emergency changes to ensure proper protocol and SODs were followed. Infrastructure ITGCs Consideration of Blockchain has Prior to a Blockchain change In-scope Layer been incorporated into ongoing being placed into production, business operations procedures, operations policies and forms and processes. procedures have been updated to include integration with Blockchain to ensure the business end users are aware of the Blockchain impact. Infrastructure Business Upon identified of a processing Back out plans for Blockchain In-scope Layer Continuity and error, management enables back configuration and plan to roll Disaster Recovery out/back up plan including the over to human processors in Blockchain being removed from case of a Blockchain failure production. are formally documented for each Blockchain configuration and routinely reviewed to ensure still complete and accurate Infrastructure Business IT disaster recovery and business Disaster recovery plan for the In-scope Layer Continuity and continuity plans have been Blockchain technology exists Disaster Recovery developed based on the framework for prolonged outages (with and designed to reduce the impact internal systems or 3rd party of a major disruption on the vendors) and has been tested Blockchain functions and processes. to limit impact business The plans are based on risk operations. understanding of potential business impacts and address requirements for resilience, alternative processing and recovery capability of all critical IT services including the Blockchain use case. The plan is tested on a semi-annual basis. Infrastructure Business Backups of information are The Blockchain configuration In-scope Layer Continuity and conducted, maintained, and tested tools and data is included in Disaster Recovery semi-annually management standard backup and recovely plan to ensure data is backed up within data centers or the cloud and available if needed. Infrastructure Business IT disaster recovery and business Risks to business continuity In-scope Layer Continuity and continuity plans have been due to prolonged outages Disaster Recovery developed based on the framework (with internal systems or with and designed to reduce the impact 3rd party vendor) have been of a major disruption on the identified and procedures Blockchain Instance functions and have been formally processes. The plans are based on documented to mitigate any risk understanding of potential risks. business impacts and address requirements for resilience, alternative processing and recovely capability of all critical IT services including the Blockchain use case. The plan is tested on a semi-annual basis. Infrastructure Business Business Continuity and Disaster Business Continuity and In-scope Layer Continuity and Recovery plans are tested semi- Disaster Recovery plans are Disaster Recovery annually to validate that the plans tested semi-annually to verify meet the organizational the validity of established and requirements. implemented information security controls and to take appropriate corrective actions. Infrastructure Business Recovery activities are Communication occurs to the In-scope Layer Continuity and communicated to internal individuals and teams Disaster Recovery stakeholders and executive and involved in the recovery plan management teams prior to and to ensure key stakeholders during declared outages. understand their responsibilities in the event of an outage. Infrastructure IT Asset The Blockchain vendors are The Blockchain vendors are In-scope Layer Management monitored for compliance with monitored on an ongoing contractual agreements. basis to ensure compliance with contractual agreements. Infrastructure IT Asset Licensing agreements are The Blockchain licensing In-scope Layer Management monitored and renewed as needed. agreements are reviewed, tracked and renewed as needed. Infrastructure IT Asset The Blockchain program policies The Blockchain vendor In-scope Layer Management and procedures, which includes selection was based on formal formal the Blockchain vendor selection methodology and selection methodology and detailed business standard contract templates and requirements. requirements, are reviewed and approved on a periodic basis. Infrastructure IT Asset The Blockchain program policies The Blockchain vendor In-scope Layer Management and procedures, which includes contracts clarifies resource The Blockchain contract policies ownership and hardware including clarification of the procurement requirements for Blockchain ownership, are client and vendor. reviewed and approved on a periodic basis.

TABLE 10 Test Type (TBD- Risk Category Domain Test Procedure (#) As per engagement) Request List (#) Infrastructure Servers and 1. Inquire with the control owners to Inquiry, Inspection, 1. Policies and procedures Layer Databases determine if the organization and/or observation related to configuration Configuration identifies and documents established settings, specifically regarding configuration settings. Review the test plan of all functional existing documentation around test requirements for configuration. exceptions to ensure the test plans 2. Log of test exceptions. identifies all functional requirements. 2. Verify the test exceptions are recorded, monitored and tracked for resolution prior to migration to production Infrastructure Servers and 1. Verify whether a configuration Inquiry, Inspection, 1. Policies, procedures, related Layer Databases management program is documented and/or observation to the baseline configuration Configuration and maintained settings on production infrastructures. Infrastructure ITGCs 1. Inquire with the control owner and Inquiry, Inspection, 1. Change Management Layer determine that the organization has a and/or observation policies, procedures, and documented Change Management standards Process and it is reviewed at least 2. Evidence of the last review annually and updated as needed. of documented Change 2. Obtain a list of changes that were Management Process. migrated to production for the testing 3. Population of changes for period. the applications and systems 3. Select a sample of changes made to 4. Evidence of change requests the production environment and and approvals determine if it was documented, tested prior to migration to production, and approved by the appropriate personnel. 4. Inspect that appropriate SOD is implemented for roles and environments. Infrastructure ITGCs 1. Inquire with control owners to Inquiry, Inspection, 1. Screen-prints for each of the Layer determine that the development/ and/or observation following environments: testing environments are separate development from the production environment. testing 2. Obtain and inspect screen-prints of production the development, testing, and 2. Evidence of access control production environment to determine settings to enforce separation that they are in different between development/testing environments. and production environments. Infrastructure ITGCs 1. Determine through interviews with Inquiry, Inspection, 1. Evidence of segregation of Layer control owners whether access and/or observation duties in place for each in- controls are defined, documented, scope information system. approved and enforced for changes to information systems. Infrastructure ITGCs 1. Inspect relevant backup Inquiry, Inspection, 1. Backup policies and Layer documentation and inquire with the and/or observation procedures control to validate whether the 2. Screenshot of backup following considerations have been configuration settings determined, documented, and 3. Backup log showing status implemented. of backups 2. Inspect the backup confirmation 4. Evidence of successful settings and frequency to determine backup restoration whether it is in accordance with 5. Reports detailing testing policies and procedures. efforts and the results of the 3. Review activity logs for backups to testing efforts determine the completeness of the 6. Evidence of backup organizations backup efforts. schedule 4. Review activity logs for backups to determine if an alert is configured to notify administrators of successful and failed backups. 5. Review detailing testing efforts and the results of the testing efforts. Infrastructure ITGCs 1. Inquire with management to Inquiry, Inspection, 1. Provide the input validation Layer determine if the production systems and/or observation rules/configuration on the and applications have built in production systems and detective alerts if an invalid input is applications. received and an error message is generated. 2. Inspect the input validation rules and program logic on the production systems and applications to determine if input validation checks are appropriately configured to validated information entered into a data field. Infrastructure ITGCs 1. Inquire with control owners to Inquiry, Inspection, 1. Blockchain use case risk and Layer determine the review and approval and/or observation control matrix with approval process for additional controls from a redesign. 2. Review an updated risk and control matrix and inspect for evidence of approval Infrastructure ITGCs 1. Inquire with control owners to Inquiry, Inspection, 1. Information Security Policy Layer determine whether the organization and/or observation of Access revokes user account access in Provisioning/Deprovisioning response to terminations. Policy 2. Obtain and inspect policies and 2. Population of total procedures to determine the terminated users requirements are clearly stated for the 3. Evidence that access is removal of logical access as a result revoked within the timeframe of terminations. specified by the access control 3. Select a sample of terminated users procedures and inspect the evidence to determine that access is revoked within the timeframe specified by the access control procedures. Infrastructure ITGCs 1. Inquire with control owners to Inquiry, Inspection, 1. Information Security Policy Layer determine the review and approval and/or observation of Access process for access requests. Provisioning/Deprovisioning 2. Obtain the population of access Policy requests and inspect the evidence to 2. User access requests determine that access is properly 3. Evidence that access is reviewed and approved by reviewed and approved by management. management Infrastructure ITGCs 1. Inquire with control owners who is Inquiry, Inspection, 1. Information Security Policy Layer responsible for assigning access to and/or observation of Access verify that access to privileged user Provisioning/Deprovisioning IDs are appropriate and restricted. Policy 2. Obtain and inspect documentation 2. Population of users with to determine that privileged access privileged access requests are evaluated for 3. Evidence for selected appropriateness and follow the samples, indicating the job principles of least privilege. function(s) or role(s) 3. Obtain a population of users with requested, as well as the privileged access and select a sample approval for the access of users and inspect evidence to requested. determine the access is necessary and 4. List of privileged user approved by the designated authority. accounts and associated roles. 5. Access approval matrix Infrastructure ITGCs 1. Inquire with management and Inquiry, Inspection, 1. Physical access policies and Layer inspect the documented process to and/or observation procedures determine if procedures are defined 2. Populationof new users for authorizing and granting physical 3. Access lists to in-scope access to employees, contractors, and facilities and equipment visitors based on role or function. 2. Obtain a population of new users who have been granted access to the in-scope facilities and equipment. 3. Select a sample of new users and inspect that physical access was authorized and documented prior to physical access granted. Infrastructure ITGCs 1. Inquire with management the key Inquiry, Inspection, 1. Key card system Layer card system implementation process. and/or observation implementation policy 2. Inquire/Observe with management 2. Key card system access list that video surveillance is in place at 3. Key card system logs to the the data centers. data centers 3. Obtain the key card system logs to the data centers. 4. Select a sample of users granted access to the data center and inspect that key card access was authorized and documented prior to physical access granted. Infrastructure ITGCs 1. Obtain the key card system log to Inquiry, Inspection, 1. Key card system logs to the Layer the data center operations and select a and/or observation data center operations sample of users to inspect the 2. Evidence of recertifications recertification occurs on a semi- for users with physical access annual basis. Infrastructure ITGCs 1. Determine through interviews with Inquiry, Inspection, 1. Evidence of segregation of Layer control owners whether access and/or observation duties in place for each in- controls are defined, documented, scope information system. approved and enforced for changes to information systems and critical business processes. Infrastructure ITGCs 1. Examine the documentation and Inquiry, Inspection, 1. Screenshots of password Layer security parameters to verify they are and/or observation configurations aligned 2. Password policy Infrastructure ITGCs 1. Inquire with control owner and Inquiry, Inspection, 1. Information Security Policy Layer determine that the organization has a and/or observation of Access documented recertification policy and Provisioning/Deprovisioning it is reviewed at least annually and Policy updated as necessary. 2. Evidence of recertifications 2. Select a sample of recertifications for the Blockchain Operational for the Blockchain Operational governance tools governance tools over the testing 3. Evidence of users job period and inspect the evidence to function and role determine the appropriate personnel confirmed the access and the access based on the job function and role is appropriate. Infrastructure ITGCs 1. Inquire with control owner and Inquiry, Inspection, 1. Change Management Policy Layer determine that the organization has a and/or observation inclusive of Blockchain documented Blockchain change policies approval policy and procedure and 2. If available, Blockchain inspect it includes key controls, policy oversight and escalation procedures. Infrastructure ITGCs 1. Inquire with control owner and Inquiry, Inspection, 1. Blockchain Governance Layer determine that the organization has a and/or observation Framework documented Blockchain governance 2. Evidence of approved framework. changes 2. Select a sample of approved 3. Job Scheduler changes and inspect the appropriate personnel approved the change and it was tested in accordance with the Blockchain governance framework. Infrastructure ITGCs 1. Inquire with control owner and Inquiry, Inspection, 1. Problem Management Layer determine that the organization has a and/or observation Process for Blockchain documented problem management Configurations process for Blockchain 2. Blockchain Configurations Configurations. error or exceptions log 2. Select a sample of errors or exceptions and inspect the evidence to ensure they were tracked, escalated, root causes identified and resolved. Infrastructure ITGCs 1. Inquire with control owner and Inquiry, Inspection, 1. Information Security Policy Layer determine that the organization has a and/or observation of Access documented recertification policy and Provisioning/Deprovisioning it is reviewed at least annually and Policy updated as necessary. 2. Evidence of recertifications 2. Select a sample of recertifications for the Blockchain for the Blockchain configuration tools configuration tools over the testing period and inspect the 3. Evidence of users job evidence to determine the appropriate function and role personnel confirmed the access and the access based on the job function and role is appropriate. Infrastructure ITGCs 1. Inquire with control owner to Inquiry, Inspection, 1. Change Management Layer determine if a Change Management and/or observation policies, procedures, and policy exists and it is updated as standards needed. 2. Evidence of the last review 2. Inspect the policy to ensure of documented Change emergency changes to Blockchain Management Process. configuration is included. 3. Population of emergency 3. Select a sample of emergency changes for the applications changes to Blockchain configurations and systems and inspect the evidence to ensure 4. Evidence of emergency policies were followed and the change and approvals appropriate personnel approved the change. Infrastructure ITGCs 1. Inquire with control owner to Inquiry, Inspection, 1. Blockchain Operations Layer determine if a Blockchain Operations and/or observation policy and procedures policy exists and it is updated as 2. Evidence of a Blockchain needed. change 2. Inspect the evidence of a Blockchain change to ensure the policies and procedures have been updated to include the updated integration Infrastructure Business 1. Inquire with the control owner to Inquiry, Inspection, 1. Back out plan Layer Continuity determine if a formal Blockchain and/or observation 2. Blockchain and Disaster failure plan exists. failure plan Recovery 2. Obtain the most recent version of 3. Business Continuity plan business continuity and disaster recovery plans and verify a back out plan is included for Blockchain. Infrastructure Business 1. Inquire with the control owner to Inquiry, Inspection, 1. Business Continuity and Layer Continuity determine if a formal business and/or observation Disaster Recovery plan and Disaster continuity and disaster recovery 2. Evidence of the organization Recovery management program exists (i.e., conducting tests of outages and governance, resources, plans) documenting the results. 2. Obtain the most recent version of business continuity and disaster recovery plans and verify whether it has been approved by a Senior Management executive and includes the following: Business continuity objectives Business processes and critical information assets in scope Information security continuity Business impact analysis Recovery objectives and priorities, including Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) Roles and responsibilities Dependencies and critical functions for delivery of critical services 3. Inquire with the control owner to determine whether the business continuity and disaster recovery plans have been communicated and shared with stakeholders with associated responsibilities. 4. Inquire with control owner to determine how often the business continuity and disaster recovery plans are tested and how they document the results of the test. Infrastructure Business 1. Verify the standard backup and Inquiry, Inspection, 1. Standard backup and Layer Continuity recovery plan includes a section and/or observation recovery plan and Disaster regarding Blockchain configuration 2. Agreements for the data Recovery tools and data. center or cloud if applicable 2. Inspect the agreements with the data center or cloud providers to determine whether they exist and cover the current period. Infrastructure Business 1. Inquire with control owner and Inquiry, Inspection, 1. Business Continuity and Layer Continuity inspect evidence to determine and/or observation Disaster Recovery plan and Disaster whether the risks identified and 2. Evidence of risks identified Recovery documented have been mitigated within the business continuity and disaster recovery plan. Infrastructure Business 1. Inquire with control owner and Inquiry, Inspection, 1. Business continuity and Layer Continuity inspect evidence to determine and/or observation disaster recovery plan testing and Disaster whether the business continuity and report. Recovery disaster recovery plans are tested on a 2. Evidence that corrective semi-annually basis, if test results are actions are taken if necessary. reviewed and corrective actions are taken if necessary. Infrastructure Business 1. Inquire with control owner to Inquiry, Inspection, 1. Information Security Layer Continuity determine whether communication and/or observation policies and procedures and Disaster occurs to the individuals and teams 2. Business Continuity Recovery involved in the recovery processes so Management Policy that key stakeholders understand their 3. Technology Operations responsibilities in the event of a Disaster Recovery Plan disaster. Infrastructure IT Asset 1. Inspect a sample of vendors and Inquiry, Inspection, 1. Vendor contracts Layer Management validate that the vendor contracts are and/or observation 2. Population of vendors monitored periodically. Infrastructure IT Asset 1. Inspect a sample of vendors and Inquiry, Inspection, 1. Vendor licensing Layer Management validate that the vendor licensing and/or observation agreements agreements are monitored 2. Population of vendors periodically and renewed as needed. 3. Log of tracking vendor licensing agreements Infrastructure IT Asset 1. Inquire with the control owner and Inquiry, Inspection, 1. Vendor management policy Layer Management determine if a vendor management and/or observation and procedure policy exists. 2. Vendor contracts 2. Inspect a sample of agreements and 3. Population of new vendors validate that the policy and for the testing period procedures were reviewed and approved on a periodic basis. 3. Verify each Blockchain vendor includes the standard contract, templates and requirements that are aligned with the vendor selection Infrastructure IT Asset 1. Inquire with the control owner and Inquiry, Inspection, 1. Vendor management policy Layer Management determine if all relevant information and/or observation and procedure security requirements are established 2. Vendor contracts and agreed with each supplier/vendor 3. Population of new vendors that may access, process, store, for the testing period communicate, or provide IT infrastructure components for, the organizations information. 2. Inspect a sample of agreements and validate they include resource ownership, hardware procurement requirements, and Blockchain ownership.

4.4 Architecture Layer Assessment Work Program

In some embodiments, blockchain architecture layer risk category in the blockchain risk framework covers relevant risks, control objectives and descriptions, testing objectives and procedures, and reporting parameters designed to address assurance and compliance needs for the blockchain architecture stack/layer supporting blockchain permissioned and/or permissioned networks operations and participant lifecycle management.

The sub-risk categories, control and testing objectives, test procedures and request lists for Architecture Layer risk category are provided below in Tables 11-13.

TABLE 11 Risk Level Risk Risk (L, M, H) Risk Category Domain Classification Number Risk Description (As applicable) Architecture Layer Blockchain Strategic, AL-BP1 Lack of an established baseline for L, M, H Platform & Operational, Blockchain systems may affect Protocol Financial, operational environments and Configuration Compliance, compromise security. Legal, or Reputational Architecture Layer Blockchain Strategic, AL-BP2 If hardening standards have not been L, M, H Platform & Operational, developed, defined, or implemented. Protocol Financial, Blockchain systems are unprotected Configuration Compliance, and vulnerable to malicious attacks. Legal, or Reputational Architecture Layer Blockchain Strategic, AL-BP3 Inadequate processes in the design L, M, H Platform & Operational, phase of the Blockchain Protocol Financial, implementation may negatively Configuration Compliance, impact core system performance. Legal, or Reputational Architecture Layer Blockchain Strategic, AL-BP4 Lack of configuration standards L, M, H Platform & Operational, and/or lack of adherence to Protocol Financial, established configuration standards Configuration Compliance, may lead to failures or inefficiencies Legal, or in the Blockchain production Reputational environment. Architecture Layer Blockchain Strategic, AL-BP5 Lack of configuration standards L, M, H Platform & Operational, and/or lack of adherence to Protocol Financial, established configuration standards Configuration Compliance, may lead to failures or inefficiencies Legal, or in the Blockchain production Reputational environment. Architecture Layer Blockchain Strategic, AL-BP7 Insufficient test plans lead to the L, M, H Platform & Operational, inability to meet the requirements Protocol Financial, identified in the analysis and design Configuration Compliance, phase. Legal, or Reputational Architecture Layer Blockchain Strategic, AL-BP8 Insufficient test plans lead to the L, M, H Platform & Operational, inability to meet the requirements Protocol Financial, identified in the analysis and design Configuration Compliance, phase. Legal, or Reputational Architecture Layer Hardware Security Strategic, AL-BP9 HSM devices are properly L, M, H Modules Operational, configured and maintained Financial, which may expose the Blockchain use case Compliance, supporting systems or sensitive data Legal, or to unauthorized parties. Reputational Architecture Layer Signature Strategic, AL-SM1 Lack of effective cryptographic keys L, M, H Management Operational, management may expose the keys to Financial, potential modification, loss, Compliance, destruction or disclosure to Legal, or unauthorized parties. Reputational Architecture Layer Signature Strategic, AL-SM2 Lack of effective cryptographic keys L, M, H Management Operational, management may expose the keys to Financial, potential modification, loss, Compliance, destruction or disclosure to Legal, or unauthorized parties. Reputational Architecture Layer Signature Strategic, AL-SM3 Lack of effective cryptographic keys L, M, H Management Operational, management may expose the keys to Financial, potential modification, loss, Compliance, destruction or disclosure to Legal, or unauthorized parties. Reputational Architecture Layer Signature Strategic, AL-SM4 Lack of effective cryptographic keys L, M, H Management Operational, management may expose the keys to Financial, potential modification, loss, Compliance, destruction or disclosure to Legal, or unauthorized parties. Reputational Architecture Layer Cryptography Strategic, AL-C1 Inadequate protection of information L, M, H Operational, in Blockchain systems through Financial, cryptographic techniques and Compliance, effective key management may Legal, or result in the potential compromise of Reputational confidentiality or integrity of information in transmission or storage. Architecture Layer Cryptography Strategic, AL-C2 Inadequate protection of information L, M, H Operational, in Blockchain systems through Financial, cryptographic techniques and Compliance, effective key management may Legal, or result in the potential compromise of Reputational confidentiality or integrity of information in transmission or storage. Architecture Layer Cryptography Strategic, AL-C3 Inadequate protection of information L, M, H Operational, in Blockchain systems through Financial, cryptographic techniques and Compliance, effective key management may Legal, or result in the potential compromise of Reputational confidentiality or integrity of information in transmission or storage. Architecture Layer Cryptography Strategic, AL-C4 Inadequate protection of information L, M, H Operational, in Blockchain systems through Financial, cryptographic techniques and Compliance, effective key management may Legal, or result in the potential compromise of Reputational confidentiality or integrity of information in transmission or storage. Architecture Layer Cryptography Strategic, AL-C5 Lack of compliance may result in L, M, H Operational, ineffective controls thereby Financial, heightening organization′s security Compliance, and compliance risks. Legal, or Reputational Architecture Layer Scalability /Capacity Strategic, AL-SC1 System capacity is not monitored L, M, H Management Operational, which may lead to interruption Financial, and/or failure to key systems. Compliance, Legal, or Reputational Architecture Layer Scalability/Capacity Strategic, AL-SC2 Inadequate procedures to monitor L, M, H Management Operational, the capacity and performance of IT Financial, resources may lead to delivery Compliance, failure of service performance Legal, or agreements. Reputational Architecture Layer Scalability/Capacity Strategic, AL-SC3 Failure to define, agree, record and L, M, H Management Operational, manage the levels of service as Financial, required by the business may result Compliance, in the agreed service continuity and Legal, or availability commitment to Reputational customers not being met in all circumstances. Architecture Layer Availability Strategic, AL-A1 Lack of redundant information L, M, H Operational, processing facilities may lead to Financial, disruption of critical services in the Compliance, event Blockchain information Legal, or processing facilities are unavailable Reputational due to excess capacity or other threats. Architecture Layer Encryption (EN) Strategic, AL-EN01 Privileged access is not L, M, H Operational, appropriately restricted, logged, and Financial, monitored for unencrypted data, Compliance, which can lead to unauthorized Legal, or access Reputational Architecture Layer Encryption (EN) Strategic, AL-EN02 Data in transit is not secure and may L, M, H Operational, be compromised or accessed by Financial, unauthorized participants, Compliance, compromising the integrity of the Legal, or data Reputational Architecture Layer Encryption (EN) Strategic, AL-EN03 Data at rest or in storage is not L, M, H Operational, secure and may be accessible by Financial, unauthorized participants, Compliance, compromising the integrity of the Legal, or data Reputational Architecture Layer Encryption (EN) Strategic, AL-EN04 Databases lack encryption to protect L, M, H Operational, and recover data in the case of loss Financial, or theft Compliance, Legal, or Reputational Architecture Layer Encryption (EN) Strategic, AL-EN05 Data is not retained for DLT inputs. L, M, H Operational, PKIs, or other critical systems; lack Financial, of availability limits backup and Compliance, recovery capability Legal, or Reputational Architecture Layer Encryption (EN) Strategic, AL-EN06 PKI Certificate Authority (CA) is L, M, H Operational, insufficiently isolated from tire rest Financial, of the network Compliance, Legal, or Reputational Architecture Layer Encryption (EN) Strategic, AL-EN07 No PKI Certificate Authority (CA) L, M, H Operational, is present in the organization′s Financial, network to validate data Compliance, transmission or transactions on the Legal, or blockchain Reputational Architecture Layer Key Management Strategic, AL-EN07 Lack of proper physical and logical L, M, H Operational, custody of the keys (private and Financial, public) can compromise a single or Compliance, multiple users on the Blockchain. Legal, or Reputational Architecture Layer Data Retention Strategic, AL-DR01 Data is not retained for DLT inputs, L, M, H (DR) Operational, PKIs, or other critical systems; lack Financial, of availability limits backup and Compliance, recovery capability Legal, or Reputational Architecture Layer Consensus (CS) Strategic, TL-CS01 No formal consensus protocol is L, M, H Operational, established, system validators for Financial, DLT entries lacks authentication Compliance, Legal, or Reputational Architecture Layer Consensus (CS) Strategic, AL-CS02 Implementation processes for L, M, H Operational, system coding related to consensus Financial, have not been defined: no formal Compliance, channel for change management Legal, or exists Reputational Architecture Layer Consensus (CS) Strategic, AL-CS03 System development and L, M, H Operational, management life cycle does not Financial, exist or does not apply to Compliance, consensus system architecture Legal, or Reputational Architecture Layer Consensus (CS) Strategic, AL-CS04 The organization has no approvals L, M, H Operational, process for change management Financial, affecting consensus or docs not Compliance, secure against improper approvals Legal, or being issued Reputational Architecture Layer Consensus (CS) Strategic, AL-CS05 There is no access review or audit L, M, H Operational, mechanism for the consensus Financial, protocol or any users, systems, or Compliance, participants affiliated with DLT Legal, or validation Reputational Architecture Layer Consensus (CS) Strategic, AL-BC1 Consensus mechanisms L, M, H Operational, implemented do not provide comfort Financial, on the immutability of the data Compliance, stored on the Blockchain. Legal, or Reputational Architecture Layer Consensus (CS) Strategic, AL-BC2 Consensus mechanisms L, M, H Operational, implemented do not provide comfort Financial, on the immutability of the data Compliance, stored on the Blockchain. Legal, or Reputational

TABLE 12 In-scope/Out- Risk of-Scope (TBD- Category Domain Control/Test Objective Control Description As per engagement) Architecture Blockchain Platform & The organization has created A configuration management In-scope Layer Protocol Configuration a configuration management program and database exists to database (CMDB) that implement, maintain and control houses all Blockchain configuration of Blockchain systems and infrastructure. systems and oilier infrastructure A baseline configuration of elements (including hardware, the Blockchain system is software, firmware, and created, implemented, and documentation). The program maintained. requires the identification of baseline configurations (original versions) of Blockchain infrastructure elements (hardware, software etc.). A central repository of configuration items (Cl), their attributes, and their inter-linkages is established and maintained. CIs are linked to the services that they support. Current and prior configuration for all CIs, including Blockchain production servers, network devices, and databases is captured and maintained in the central repositon. in order to support rollback Architecture Blockchain Platform & Blockchain systems Blockchain system configuration In-scope Layer Protocol Configuration hardening standards arc and hardening standards arc established and maintained. developed, communicated, Blockchain system implemented and maintained. The configuration and hardening standards followed address all standards are consistent known security vulnerabilities and with industry-accepted are consistent with industry- standards, vendor specific accepted system hardening guidelines and address all standards and any vendor specific known security guidelines vulnerabilities Architecture Blockchain Platform & The Blockchain Instance The Blockchain Instance process In-scope Layer Protocol Configuration impact on core processing impact on core system system performance has performance is documented and been determined and approved by IT and the appropriately addressed as Blockchain Instance program part of functional management. specification process Architecture Blockchain Platform & Newly implemented the Once the Blockchain Instance has In-scope Layer Protocol Configuration Blockchain Instances are been configured, a test plan is configured to completely or developed to ensure meeting all accurately process data. functional requirements and The Blockchain Instances approved by the Blockchain are configured to effectively Instance program management. meet the business The Blockchain Instance requirements. configurations are tested by the impacted/required business and/or the Blockchain Instance program management team. Test exceptions are appropriately recorded, monitored and tracked for resolution prior to migration to production. Architecture Blockchain Platform & Auditability of the The audit logging of the In-scope Layer Protocol Configuration Blockchain Instance Blockchain Instance software tool processing has been enabled has been enabled. The ability to within the tool. change the audit capacities is restricted to authorized personnel outside of the configuration function. Architecture Blockchain Platform & Testing architecture and Once the Blockchain Instance has In-scope Layer Protocol Configuration requirements have been been configured, a test plan is defined and documented. developed to ensure meeting all Test plan including test functional requirements and cases and procedures are approved by the Blockchain formally defined. Instance program management. The Blockchain Instance configurations are tested by the impacted/required business and/or the Blockchain Instance program management team. Test exceptions are appropriately recorded, monitored and tracked for resolution prior to migration to production. Architecture Blockchain Platform & Technical test environments The Blockchain Instance In-scope Layer Protocol Configuration are stable and managed configuration testing take place in properly. environments which are logically segregated from and mirror the legacy system production environment. Architecture Hardware Security HSM devices are properly HSM devices are deployed, In-scope Layer modules configured and maintained properly configured and which may expose the maintained to prevent the Blockchain use case Blockchain use case supporting supporting systems or systems or sensitive data exposure sensitive data to to unauthorized parties unauthorized parties Architecture Signature Management The integrity of the A formal key management system In-scope Layer Blockchain cryptosystem is and associated processes exist to maintained through the securely manage (i.e.. generate, proper management of distribute, store, access, backup encryption keys. Public and and destroy) secret/private keys private keys are securely and public keys issued by trusted managed through formal Certification Authorities. Formal management processes. procedures are in place to protect keys used to secure stored cardholder data against disclosure and misuse. Public key certificates are issued per defined standards or from an approved service provider. Architecture Signature Management The integrity of the 1. Examine user access lists to In-scope Layer Blockchain cryptosystem is verify that access to keys is maintained through the restricted to the fewest number of proper management of custodians necessary encryption keys. 2. Verify whether equipment used Cryptographic key access to generate, store, and archive and storage is restricted and keys are protected. controlled. Architecture Signature Management The integrity of the Cryptographic keys are stored in In-scope Layer Blockchain cryptosystem is the fewest locations possible. maintained through the Secret mid private keys used to proper management of encrypt/decrypt cardholder data encryption keys. are stored in one (or more) of the Cryptographic keys arc following forms at all times: securely stored. Encrypted with a key-encrypting The integrity of the key that is at least as strong as the Blockchain cryptosystem is data-encrypting key, and that is maintained through the stored separately from the data- proper management of encrypting key encryption keys. Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS- approved point-of-interaction device) As at least two full-length key components or key shares, in accordance with an industry- accepted method Architecture Signature Management The integrity of the Cryptographic keys are changed at In-scope Layer Blockchain cryptosystem is the end of their cryptoperiod. as maintained through the defined by the associated proper management of application vendor or key owner, encryption keys. and based on industry best Cryptographic key change practices and guidelines. Keys arc management is followed in retired or replaced (for example, accordance with best archiving, destruction, and/or practices and guidelines. revocation) as deemed necessary when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key component), or keys are suspected of being compromised. Architecture Cryptography Control: Stored classified Classified data (e.g.. CUI, PHI. In-scope Layer data are encrypted and CHD. PII) is stored in an access controlled. encrypted format regardless of the Control Objective: Data-at- medium (including mobile rest is protected through devices). Access to the encryption cryptographic techniques. keys is restricted to authorized personnel. Architecture Cryptography Data-at-rest is protected Logical access for disk encryption In-scope Layer through cryptographic is managed separately and techniques. Disk encryption independently of native operating managed independently of system authentication. the native operating system authentication. Architecture Cryptography Data-in-transit is protected Cryptographic techniques are used In-scope Layer through cryptographic to protect the confidentiality and techniques. Data integrity in integrity of data in transmission. transmission protected with While transmitting cardholder secure cryptography. data, the following measures are implemented: Only trusted keys and certificates are accepted. The protocol in use only supports secure versions or configurations. The encryption strength is appropriate for the encryption methodology in use. Architecture Cryptography Data-in-transit is protected Secure messaging utilities and In-scope Layer through cryptographic facilities are used to protect data in techniques. Data is transmission. Electronic protected in transmission messaging such as MQ Series, through secure messaging middleware, system to system utilities and facilities. application calls, batch processing, email. Electronic Data Interchange (EDI), and instant messaging, has security provisions in place to protect messages from unauthorized access, modification, and denial of service. Architecture Cryptography Cryptographic controls Cryptographic controls are used in In-scope Layer comply with relevant compliance with all relevant agreements, legislation, and agreements, legislation, and regulations. Cryptographic regulations. FIPS-validated controls have been cryptography is leveraged to established to comply with protect the confidentiality of CUI. all business relevant If cryptography is required based agreements, legislation, and on the selection of other security regulations. controls, each type of cryptography required is clearly defined. Architecture Cryptography System capacity is Real time monitoring of system In-scope Layer monitored in real time to capacity is performed to enable the meet availability implementation of additional requirements. System capacity to help meet availability capacity is monitored for commitments and requirements, operations regarding and reports are made available for information processing management review. facilities Architecture Scalabiltiy/Capacity Adequate capacity is Availability requirements are In-scope Layer Management maintained to prevent agreed upon with customers. interruptions. System Availability, capacity, and capacity is adequately performance baselines have been monitored to ensure system established based on customer availability is maintained. needs, business impact analysis, organizational policies etc. Adequate capacity, performance, and availability is maintained to prevent business disruptions, and to meet existing and changing business needs. Architecture Scalabiltiy/Capacity Baselines are monitored for Deviations from established In-scope Layer Management deviations and are resolved availability, performance, and or followed up. Maintain capacity baselines are monitored, service availability, efficient reported, and resolved. After management of resources, monitoring, measuring, analyzing, and optimization of system reporting, and reviewing performance through availability, performance, and prediction of future capacity deviations from performance and capacity established baselines, all requirements. outstanding issues are followed up. Architecture Availability Blockchain production Blockchain production systems In-scope Layer system availability is are monitored for availability and monitored and incidents are any incidents are documented in a documented. Technical ticketing system. capabilities exist to enable resiliency of Blockchain information processing facilities in accordance with availability objectives in the event of disruption.

TABLE 13 Test Type Risk (TBD-As per Category Domain Test Procedure (#) engagement) Request List (#) Architecture Blockchain 1. Inquire with the control owner to Inquiry, 1. Policies, procedures, Layer Platform & determine whether a configuration Inspection, and/or related to the Blockchain Protocol management database (CMDB) that observation baseline configuration Configuration includes Blockchain configuration settings on production items (Cl) is maintained. infrastructures. 2. Verify whether a configuration 2. Enterprise Blockchain management plan is documented and production infrastructure maintained and includes the following: configuration management Roles and responsibilities plan. Process for identifying and managing CIs Definitions of CI Interlinkages between CIs 3. Inspect the CMBD and determine for a sample of systems, where the Blockchain baseline configuration is maintained. Also, validate whether previous versions of the CIs and corresponding documentation is archived and maintained to support rollback. 4. Verify whether the CMDB is reviewed for accuracy and consistency on a periodic basis. Verify whether the organization reviews and updates the baseline configuration of the Blockchain system on a periodic basis or upon any upgrades or installations. Architecture Blockchain 1. Inquire with control owner to Inquiry, 1. Provide evidence of the Layer Platform & determine if the organization: Inspection, and/or organization′s documented Protocol Establishes and documents observation change management Configuration configuration settings for Blockchain methodology for the technology products employed within production environment. the information system using the 2. Provide evidence of appropriate security configuration Blockchain Network baseline that reflect the most restrictive Hardening Guidelines. mode consistent with operational Production Network requirements: Security Standard, and Implements the configuration settings; Change Management 2. Inquire of the control owner and methodology. determine the Blockchain system 3. Change Management configuration standards are consistent methodology with industry-accepted configuration 4. Production Network and hardening standards and are applied Security Standard. when new systems are configured and 5. Blockchain verified as being in place before a Infrastructure Hardening Blockchain system is installed on the Guidelines. network. 3. Inspect the Network Hardening Guidelines. Production Network Security Standard, and Change Management methodology and determine if the organization has documented and implemented a change management methodology for the production environment to govern the Blockchain configuration management process. Architecture Blockchain 1. Inquire with control owner to Inquiry, 1. SDLC policies and Layer Platform & whether an established system Inspection, and/or procedures. Protocol development lifecycle process is in observation 2. Evidence that an Configuration place, documented, maintained, and established system applied for all Blockchain system and development lifecycle software design, acquisition, process is in place, implementation, configuration, documented, maintained integration, testing, modification, and for the development or maintenance. installation of Blockchain 2. Obtain and inspect SDLC policies systems. and procedures to determine whether mi 3. Performance established Blockchain system requirements for development lifecycle process is Blockchain information documented. systems and information 3. Verify whether an impact assessment services are identified. and performance requirements for Blockchain information systems and information services are identified as part of SDLC efforts, business process re-design, etc. Architecture Blockchain 1. Obtain Blockchain systems Inquiry, 1. Obtain Blockchain Layer Platform & configurations. Inspection, and/or systems configurations. Protocol 2. Assess configuration relative to observation Configuration functional requirements. Architecture Blockchain 1. Obtain Blockchain systems Inquiry, 1. Obtain Blockchain Layer Platform & configurations. Inspection, and/or systems configurations. Protocol 2. Assess Audit logging capabilities in observation Configuration the Blockchain system relative to internal guidelines and leading practices. Architecture Blockchain 1. Obtain Blockchain systems test plans Inquiry, 1. Obtain Blockchain Layer Platform & and requirements. Inspection, and/or systems executed test plans Protocol 2. Determine if the test plans are observation and requirements. Configuration executed as per requirements. Architecture Blockchain 1. Obtain information including version Inquiry, 1. Obtain information Layer Platform & numbers of the test and production Inspection, and/or including version numbers Protocol environments for Blockchain systems. observation of the test and production Configuration 2. Determine if the testing takes place in environments for environments which are logically Blockchain systems. segregated from and mirror the legacy system production environment. Architecture Hardware Security Determine if HSM device(s) are Inquiry, 1. Obtain HSM information Layer Modules deployed, properly configured and Inspection, and/or including vendor, maintained to prevent the Blockchain observation configuration and leading use case supporting systems or sensitive practices guidelines. data exposure to unauthorized parties. Architecture Signature 1. Review key management procedures Inquiry, 1. Encryption and Key Layer Management and determine if they address secure Inspection, and/or Management policies and generation, distribution, storage, observation procedures. backup, and access management of 2. User access list of keys. cryptographic key 2. Review key management standards to custodians. determine key strength aligns with 3. Information Security industry leading standards. policies and procedures 3. Determine through interview with 4. Security Incident control owner that formal roles and Response Process responsibilities have been established 5. Audit and for management keys. accountability policies. 4. Examine key-management policies 6. Procedures addressing and procedures to verify processes arc non-repudiation. specified to protect keys against 7. Automated mechanisms disclosure and misuse and include at configured with non- least the following: repudiation capabilities. Access to keys is restricted to the fewest number of custodians necessary. Key-encrypting keys are at least as strong as the data encrypting keys they protect. Key-encrypting keys are stored separately from data encrypting keys. Keys are stored securely in the fewest possible locations and forms. 5. Verify that key-management procedures specify how to generate strong keys. 6. Observe the method for generating keys to verify that strong keys are generated. 7. Observe the method for distributing keys to verify that keys are distributed securely. 8. Observe the method for storing keys to verify that keys are stored securely. Architecture Signature 1. Inquire about Key Management Inquiry, 1. Obtain Key Management Layer Management process. Inspection, and/or policies and procedure 2. Review the key Management process observation 2. Test approval, SOD and and determine if appropriate level of ownership activities for approval, SOD, and ownership Key Management mechanisms are in place. 3. Test approval. SOD. and ownership mechanisms to determine if the Key Management process is safe, secure and docs not lack required level of integrity. Architecture Signature 1. Examine key storage locations and Inquiry, 1. Identify and assess key Layer Management observe processes to verify that keys are Inspection, and/or storage locations, stored in the fewest possible locations. observation documented procedures, 2. Examine documented procedures to system configurations. verify that cryptographic keys used to encrypt/decrypt cardholder data must only exist in one (or more) of the following forms at all times. Encrypted with a key-encrypting key that is at least as strong as the data- encrypting key, and that is stored separately from the data-encrypting key Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved point- of-interaction device) As key components or key shares, in accordance with an industry-accepted method 3. Examine system configurations and key storage locations to verify that cryptographic keys used to encrypt/decrypt cardholder data exist in one (or more) of the following form at all times. Encrypted with a key-encrypting key Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved point- of-interaction device) As key components or key shares, in accordance with an industry-accepted method 4. Wherever key-encrypting keys are used, examine system configurations and key storage locations to verify: Key-encrypting keys are at least as strong as the data-encrypting keys they protect Key-encrypting keys are stored separately from data-encrypting keys. Architecture Signature 1. Verify that key-management Inquiry, 1. Identify and assess Layer Management procedures include a defined crypto Inspection, and/or encryption mechanism for period for each key type in use and observation Key Management define a process for key changes at the end of the defined cryptoperiod (s) ( (for example, after a defined period of time has passed and/or after a certain amount of cipher-text has been produced by a given key) 2. Interview personnel to verify that keys are changed at the end of the defined cryptoperiod(s). 3. Verify that key-management procedures specify processes for the following: The retirement or replacement of keys when tire integrity of the key has been weakened The replacement of known or suspected compromised keys. Any keys retained after retiring or replacing are not used for encryption operations 4. Interview personnel to verify the following processes are implemented: Keys are retired or replaced as necessary when the integrity of the key has been weakened, including when someone with knowledge of the key leaves the company. Keys are replaced if known or suspected to be compromised. Any keys retained after retiring or replacing are not used for encryption operations. Architecture Cryptography 1. Inquire with the control owner to Inquiry, 1. Information Security Layer determine how classified data is Inspection, and/or Policies. encrypted at rest in all formats observation 2. Data Classification (databases, media, mobile devices, Policy removable storage, etc.) and how access 3. Information Security to the encryption keys is restricted to Policy for encryption authorized personnel in accordance with requirements. encryption requirements. For data at 4. System generated list of rest, assess whether one of the individuals with access to following is implemented: the encryption keys with Full disk encryption: names and respective job Partial encryption where the access title. control will only allow writing to the 5. Configuration or encrypted partition. evidence showing systems 2. Obtain and inspect the cryptographic components/backups are controls policy to determine whether it encrypted using AES-256 aligns to industry standards. via FIPS 140-2 validated 3. Obtain a system generated list of encryption individuals with access to the 6. Evidence indicating the encryption keys and determine whether use of either full disk access is restricted to the authorized encryption, or partial personnel. encryption with access 4. Inspect that only approved hard drive controls to allow writing to encryption software has been deployed the encrypted partition to mobile devices and systems that hold sensitive data. Architecture Cryptography 1. Inquire with the control owner to Inquiry, 1. Provide the policies and Layer determine if disk encryption is used Inspection, and/or procedures related to (rather than file or column-level observation access management. database encryption). 2. Provide the 2. Inspect policies and procedures and configurations for the in the configurations for the in scope scope systems validating systems to ensure that logical access is that logical access is managed separately and independently managed separately and of native operating system independently of native authentication and access control operating system mechanisms (for example, by not using authentication and access local user account databases or general control mechanisms. network login credentials). 3. Evidence that decryption 3. Validate that decryption keys are not keys are not associated associated with user accounts. with user accounts. Architecture Cryptography 1. Inquire with control owners to Inquiry, 1. Information Security Layer determine that sensitive data is Inspection, and/or Policies and procedures encrypted while being exchanged observation related to Encryption. between systems within the network 2. Screenshots of the and also when transmitted over public applicable encryption or networks. network protection utility. 2. Identify all locations where sensitive 3. TLS implementation data is transmitted or received over system configurations. open, public networks. Examine 4. Security documented standards and compare to Implementation Guide. system configurations to verify the use of security protocols and strong cryptography for all locations. 3. Select and observe a sample of inbound and outbound transmissions as they occur (for example, by observing system processes or network traffic) to verify that all sensitive data is encrypted with strong cryptography during transit. Architecture Cryptography 1. Inspect if the organization ensures Inquiry, 1. Evidence that secure Layer that the transmission, movement, and Inspection, and/or messaging utilities and removal of information is restricted to observation facilities are used to protect authorized users and processes, and is data in transmission. protected. Thus enabling the entity to 2. Policies and procedures meet its commitments and requirements related to the protection of as they relate to security. availability, data-in-transit. processing integrity, or confidentiality or any combination thereof. 2. For the electronic messaging systems, provide screenshots and/or documentation that controls have been implemented to address the following : protecting messages from unauthorized access, modification or denial of service, ensuring correct addressing and transportation of the message, general reliability and availability of the service, legal considerations, obtaining approval prior to using external public services such as instant messaging or file sharing, stronger levels of authentication controlling access from publicly accessible networks. Architecture Cryptography 1. Inquire with control owner to Inquiry, 1. Relevant agreements and Layer determine whether cryptographic Inspection, and/or guidance for applicable controls are used in compliance with observation legislation and regulations relevant agreements, legislation, and 2. Policies and procedures regulations. related to encryption and 2. Obtain and inspect the Encryption, key management. and Cryptographic Controls. Encryption and Key Management security policies and procedures to determine that each type of cryptography is defined. Determine whether the policies outline the following: Tenant-specific encryption; Security requirements on cryptographic keys; Use of standardized cryptographic methods; Use of cryptographic keys. Architecture Scalability/Capacity 1. Inquire with the control owner and Inquiry, 1. Provide Capacity Layer Management determine if real time monitoring of Inspection, and/or Planning report system capacity is performed and the observation 2. Provide screenshots of dashboard report is available for monitoring dashboards management review. 3. ISMS Statement of 2. Inspect the capacity monitoring tools Applicability for a sample of production and sandbox instances and determine if they arc monitored in real time for. among others. CPU, API request time, web request time, transaction processing time, and report request times. 3. Inspect if monitoring dashboards are available for management review, for individual instances and in aggregate, to enable real-time monitoring and future capacity planning Architecture Scalability/Capacity 1. Verify that there is a formally Inquiry, 1. Audit and accountability Layer Management documented capacity plan associated Inspection, and/or policies and procedures with critical systems and infrastructure. observation addressing audit storage 2. Inquire with the control owner to capacity determine whether business continuity 2. Evidence showing objectives are considered while storage capacity. developing capacity plans. 3. Review the capacity plan and validate that: Required capacity is provided, taking into account aspects such as normal workloads, contingencies, storage requirements and IT resource life cycles; Provisions such as prioritizing tasks, fault-tolerance mechanisms and resource allocation practices are in place: Business criticality of systems are taken into account while determining capacity: Projections of future capacity requirements take into account business strategy and plans. Architecture Scalability/Capacity 1. Examine security policies and Inquiry, 1. Security policies and Layer Management procedures to validate a process to Inspection, and/or procedures detailing follow up on availability, performance, observation process of remediating and capacity baselines exists capacity deviations 2. Examine sample of deviations from 2. Record of capacity availability, performance, and capacity deviations and subsequent baselines and records which indicate remediation actions taken appropriate actions were taken to 3. Executive/Board address outstanding issues. reporting on handled 3. Determine through inquiry and capacity management inspection of reporting how follow up incidents. activities to deviations are tracked, measured, and reported to executives or the Board of Directors. Architecture Availability For in-scope Blockchain production Inquiry, 1. System generated list of Layer systems: Inspection, and/or incident tickets for the 1. Inquire with the control owner and observation period under review (to be determine whether production systems specified) with screenshot are monitored for availability and of parameters used to capacity, and any incidents arc generate the listing. documented in a ticketing system. 2. Incident tickets for 2. Obtain a population of incident selected sample. tickets, select a sample, and inspect the 3. Incident dashboard for ticket details for the selected sample of population of performance organization services incident tickets incidents tickets for the from the workflow ticketing system and period under review (to be determine whether the incident specified). determine the incidents were assigned 4. Tickets for the samples an impacted environment, impacted of high severity account, subject and description, performance incidents incident type, severity rating, and customer impacted and were resolved or are being actively worked to resolution. 3. Inspect the configurations within the monitoring tool for a sample of production servers, selected from the inventory management system, and determine whether the servers were configured to be monitored for availability and capacity and notify personnel in the event an issue was identified. 4. Obtain a population of incident tickets, select a sample of high severity performance incident tickets, and inspect the sample of incident tickets to determine the incidents were assigned an impacted environment, impacted account, subject and description, incident type, severity rating, and customer impacted and were resolved or are being actively worked to resolution.

In some embodiments, blockchain architecture layer risk category in the blockchain risk framework covers relevant risks, control objectives and descriptions, testing objectives and procedures, and reporting parameters designed to address assurance and compliance needs for the blockchain architecture stack/layer supporting blockchain permissioned and/or permissioned networks operations and participant lifecycle management.

The sub-risk categories, control and testing objectives, test procedures and request lists for Operational Layer risk category are provided below in Tables 14-16.

TABLE 14 Risk Level Risk Risk Risk (L, M, H) Category Domain Classification Number Risk Description (As applicable) Operational Layer Permissioned Strategic, OL-PN1 As the Blockchain is L, M, H Network Operational, implemented, the nature of the Management Financial, instance (permissioned/non Compliance, permissioned. use case etc.) is not Legal, or aligned with and the governance Reputational practices put in place. Operational Layer Participant Strategic, OL-PO1 User access controls are not L, M, H Onboarding Operational, enforced, allowing unauthorized and Off- Financial, individuals to have access to boarding Compliance, systems and SOA services. Legal, or Reputational Operational Layer Application Strategic, OL-AL1 The Blockchain technology′s L, M, H Layer Operational, impact on the controls attestations Financial, (SOC 1/SOC 2 reports) or the Compliance, Financial Statemcnt/SOX audit Legal, or scope is not assessed and therefore Reputational the potential impact is unknown and not managed. Operational Layer Application Strategic, OL-AL2 Risk and audit plans are not L, M, H Layer Operational, updated and therefore do not Financial, reflect and address the risks Compliance, associated with the Blockchain Legal, or technology. Reputational Operational Layer Blockchain Strategic, OL-BC1 Consensus mechanisms L, M, H Concensus Operational, implemented do not provide Program Financial, comfort on the immutability of the Management Compliance, data stored on the Blockchain. Legal, or Reputational Operational Layer Blockchain Strategic, OL-BC2 Consensus mechanisms L, M, H Concensus Operational, implemented do not provide Program Financial, comfort on the immutability of the Management Compliance, data stored on the Blockchain. Legal, or Reputational Operational Layer Integration Strategic, OL-IW1 The setup of the Blockchain L, M, H with off- Operational, software lacks consideration of Blockchain Financial, new security requirements to Systems and Compliance, maintain confidentiality, integrity, Processes Legal, or and availability. Reputational Operational Layer Integration Strategic, OL-IW2 Hardware (including L, M, H with off- Operational, configurations, locations, Blockchain Financial, capacity/capacity utilization, and Systems and Compliance, age and data requirements) Processes Legal, or impacted by the Blockchain Reputational integration have not been collected and evaluated, potentially causing an unknown impact. Operational Layer Integration Strategic, OL-IW3 Applications, software and L, M, H with off- Operational, software components impacted by Blockchain Financial, the Blockchain software Systems and Compliance, integration have not been Processes Legal, or identified and evaluated. Reputational Operational Layer Integration Strategic, OL-IW4 User access and segregation of L, M, H with off- Operational, duties controls are not enforced, Blockchain Financial, allowing unauthorized users to Systems and Compliance, migrate Blockchain process Processes Legal, or configurations into production. Reputational Operational Layer Integration Strategic, OL-IW5 System development or L, M, H with off- Operational, maintenance on a system with Blockchain Financial, Blockchain dependencies are not Systems and Compliance, identified and evaluated, Processes Legal, or potentially causing an unknown Reputational impact. Operational Layer Integration Strategic, OL-IW6 The legacy system Software L, M, H with off- Operational, Development Lifecycle Blockchain Financial, methodology for change Systems and Compliance, management processes docs not Processes Legal, or reflect the integration with the Reputational Blockchain program management. Operational Layer Integration Strategic, OL-IW7 Business process changes with L, M, H with off- Operational, Blockchain dependencies are not Blockchain Financial, identified and evaluated, Systems and Compliance, potentially causing an unknown Processes Legal, or impact. Reputational Operational Layer Smart Strategic, OL-SC2 Blockchain data is stored on off- L, M, H Contracts Operational, chain databases that are unsecure Financial, Compliance, Legal, or Reputational Operational Layer Smart Strategic, OL-SC3 The organization lacks a complete L, M, H Contracts Operational, governance structure to provide Financial, oversight and security for hard Compliance, forks in the blockchain Legal, or architecture Reputational

TABLE 15 In-scope/Out-of- scope (TBD-As Risk Category Domain Control/Test Objective Control Description per engagement) Operational Permissioned As the Blockchain is implemented, A Blockchain steering In-scope Layer Network there is alignment with the nature of committee, which includes Management the instance (permissioned/non executive leadership and senior permissioned. use case etc.) and the members of the business, risk, governance practices put in place. compliance and the Blockchain An appropriate governance regime is program management, meets on designed and agreed, if required a quarterly basis to conduct across all participants in the network. business performance reviews of how the Blockchain aligns with IT Governance. Operational Participant All access is logged and monitored All access is logged and In-scope Layer Onboarding and SOA services maintain the monitored. and Off- appropriate restricted access. SOA services are restricted from boarding being accessed by anyone other than whitelisted processes/clients. Operational Application Management has engaged appropriate The Blockchain Program In-scope Layer Layer members of internal and external audit management meets with external to assess if the Blockchain technology SOC 1/Financial Statement audit will have an impact on the controls teams to review the status of the attestations (SOC 1/SOC 2 reports) or project plan and future the the Financial Statement/SOX audit Blockchain process scope. considerations and management′s assessment on impact of the Blockchain technology to the audit scope. Operational Application Internal audit has been properly The Blockchain management In-scope Layer Layer engaged and the Blockchain program team meets regularly with is being considered in the internal members of risk and internal audit scoping exercises. audit in each business unit leveraging the Blockchain technology to ensure the risk and audit plans are evolving to address the Blockchain risks. Operational Blockchain As Blockchain programs are designed Blockchain consensus In-scope Layer Consensus and implemented, appropriate mechanisms that assure Program consensus mechanisms are agreed immutability are designed Management upon, implemented and controlled to implemented and the associated provide comfort on the immutability controls are documented and of the data stored on the Blockchain. approved by the business and the Appropriate controls are designed and Blockchain program implemented to safeguard the management. Blocks are created immutability of data captured on the for transactions validated blockchain. through blockchain consensus mechanism and cannot be modified once written. Operational Blockchain Conesus mechanism automatically Economic trade terms arc In-scope Layer Consensus determines whether the trade details validated through blockchain Program match between counterparties or not. consensus mechanism and Management Automatic validation will not take automatically recorded on the place if consensus is not reached. blockchain network in a timely manner. Operational Integration The Blockchain software is aligned The Blockchain software for Layer with off- with new security requirements to initial integration into the firm′s Blockchain maintain confidentiality, integrity, and environment follows a well- Systems and availability. defined integration plan and is Processes monitored by the Blockchain program management. Operational Integration Hardware impacted by the Blockchain Impact of software integration In-scope Layer with off- integration is documented and on the firm′s existing hardware Blockchain evaluated, and results are escalated to configurations, software and Systems and the Blockchain steering committee. applications is documented and Processes evaluated. The results of this evaluation are reported to the Blockchain steering committee. Operational Integration Applications and software impacted Impact of software integration In-scope Layer with off- by the Blockchain integration is on the firm′s existing hardware Blockchain documented and evaluated, and results configurations, software and Systems and are escalated to the Blockchain applications is documented and Processes steering committee. evaluated. The results of this evaluation are reported to the Blockchain steering committee. Operational Integration Operations policies and procedures Access to migrate the In-scope Layer with off- have been updated to include Blockchain process Blockchain integration with the Blockchain prior configurations into production is Systems and to the Blockchain change being placed restricted to personnel who are Processes into production. independent of the configuration team. Access to migrate the Blockchain process configurations into production is periodically reviewed to ensure access is restricted to personnel. Operational Integration Impact of legacy system development Business Unit IT management In-scope Layer with off- and maintenance on the Blockchain notifies the Blockchain program Blockchain configuration is considered during management if system Systems and legacy System Development Lifecycle development or maintenance on Processes for legacy systems. a system has been identified as Impacts to interfaces between legacy having the Blockchain systems have been identified., e.g. dependencies. The Blockchain data flow architecture program management evaluates the impact the legacy system change will have on the Blockchain. Details of the evaluation are documented. If the Blockchain process is impacted, the Blockchain is removed from production and a back out plan is enabled while a configuration change order is processed. Operational Integration An inventory, including functional The legacy system Software In-scope Layer with off- use. of all key interfaces and legacy Development Lifecycle Blockchain systems utilized by the Blockchain is methodology for change Systems and maintained. management processes has been Processes Impacts to interfaces between legacy updated to include integration systems have been identified., e.g. with the Blockchain program data flow architecture management prior to making changes to the Blockchain impacted systems or interfaces. Operational Integration The Blockchain is reconfigured when Business Unit Operations In-scope Layer with off- changes in business processes affect management notifies the Blockchain the Blockchain. Management Blockchain program Systems and considers both the downstream and management if a business Processes upstream impact of changes to process change has been business processes and the use of the identified as having the Blockchain technology. Blockchain dependencies. The Blockchain program management evaluates the impact the business process change will have on the Blockchain configuration. Details of the evaluation are documented. If a Blockchain process is impacted, the Blockchain is removed from production and back out plan is enabled while a configuration change order is processed.

TABLE 16 Test Type (TBD— Risk As per Category Domain Test Procedure (#) engagement) Request List (#) Operational Permissioned 1. Inquire with management about the process of Inquiry, 1. Listing of the Layer Network ensuring alignment with the nature of the instance Inspection, individuals on the Management and the government practices put in place. and/or Blockchain steering 2. Obtain relevant documentation evidencing the observation committee consideration of the alignment. 2. Evidence for the 3. Obtain a listing of the individuals on the most recent quarterly Blockchain steering committee. meeting (meeting 4. Obtain evidence for the most recent quarterly minutes/meeting meeting (meeting minutes/meeting invites) to invites/emails) verify that meeting took place and included showing the meeting members of the Blockchain steering committee. took place 5. Through inspection of the results of business 3. Documentation/ performance review, verify an appropriate review results of the was performed of how the Blockchain aligns with quarterly business IT Governance. performance review of how the Block- chain aligns with IT Governance 4. Documentation leveraged when considering the alignment Operational Participant 1. Inquire with management about the process Inquiry, 1. Listing of users with Layer Onboarding and frequency in which access is logged and Inspection, access to the SOA and Off- monitored. and/or services boarding 2. Obtain a listing of users with access to the observation 2. Documentation SOA services. showing all access is 3. Obtain documentation showing that all access logged and monitored is logged and monitored and through inspection, 3. Screenshot showing verify that only users with permissioned access how access is logged appear on the listing. and monitored Operational Application 1. Obtain evidence for the most recent meeting Inquiry, 1. Evidence for the Layer Layer (meeting minutes/meeting invites) to verify the Inspection, most recent meeting meeting took place and included members of the and/or (meeting Blockchain Program management team. observation minutes/meeting 2. Through inspection of the documentation of the invites/emails) assessment, verify the assessment was performed showing the meeting and the results were documented. took place 2. Documentation of management's assessment on the impact of the Blockchain technology to the audit scope Operational Application 1. Obtain evidence for the most recent meeting Inquiry, 1. Evidence for the Layer Layer (meeting minutes/meeting invites) to verify the Inspection, most recent meeting meeting took place and included members of the and/or (meeting Blockchain management team. observation minutes/meeting 2. Through inspection of an updated risk and audit invites/emails) plan, verify changes and updates have been made showing the meeting to reflect the Blockchain program. took place 2. Risk and audit plan updated to address Blockchain risks Operational Blockchain 1. Inquire with management about the process in Inquiry, 1. Documentation of Layer Consensus which appropriate consensus mechanisms are Inspection, the associated controls Program agreed upon, implemented and controlled, and/or for a new Blockchain Management 2. Obtain documentation of the associated observation consensus mechanism controls. 2. Evidence of the 3. Through inspection of documentation review and approval evidencing associated controls have been by the business and the documented, verify these controls were reviewed Blockchain program and approved by the business and the Blockchain management program management. Operational Blockchain 1. Inquire with management about the process in Inquiry, Layer Consensus which appropriate consensus mechanisms are Inspection, Program agreed upon, implemented and controlled. and/or Management 2. Obtain documentation of the associated observation controls. 3. Through inspection of documentation evidencing associated controls have been documented, verify these controls were reviewed and approved by the business and the Blockchain program management. Operational Integration 1. Inquire with management about the process of Inquiry, 1. Integration plan used Layer with off- ensuring alignment with new security Inspection, for initial integration Blockchain requirements. and/or 2. Evidence showing Systems and 2. Obtain the integration plan used for initial observation the integration plan is Processes integration. monitored 3. Through inspection of the integration plan, verify that there is evidence that the integration plan is monitored by the Blockchain program management. Operational Integration 1. Obtain the documentation of the impact of Inquiry, 1. Documentation Layer with off- software integration Inspection, showing the evaluation Blockchain 2. Through inspection of the documentation, and/or performed of the Systems and verify any impacts identified were appropriately observation impact of software Processes evaluated. integration on the 3. Obtain evidence of the communicated results firm's existing and through inspection, verify the results of the hardware evaluation were reported to the Blockchain configurations steering committee. 2. Evidence of communication to the Blockchain steering committee Operational Integration 1. Obtain the documentation of the impact of Inquiry, 1. Documentation Layer with off- software integration. Inspection, showing the evaluation Blockchain 2. Through inspection of the documentation, and/or performed of the Systems and verify any impacts identified were appropriately observation impact of software Processes evaluated. integration on the 3. Obtain evidence of the communicated results, firm's existing and through inspection, verify the results of the hardware evaluation were reported to the Blockchain configurations steering committee. 2. Evidence of communication to the Blockchain steering committee Operational Integration 1. Obtain a listing of users with access to migrate Inquiry, 1. Listing of users with Layer with off- the Blockchain process configurations. Inspection, access to migrate the Blockchain 2. Obtain evidence for the most recent periodic and/or Blockchain process Systems and review performed of access, and through observation configurations Processes inspection verify access was restricted to 2. Evidence that a personnel. periodic review was 3. Obtain the Operations policies and procedures performed of restricted Blockchain evidencing the updates made to access and including include integration with the Blockchain with evidence of the review a date in which these updates were made. 3. Operations policies 4. Obtain evidence of the Blockchain change and procedures updated being placed into production and the date in with the integration which this occurred. with Blockchain with 5. Through inspection, verify the updates were the date in which the made to the policies and procedures prior to the updates were made change being placed into production. 4. Evidence of the change being placed into production (change order ticket including the date in which the request was processed and completed) Operational Integration 1. Obtain evidence of communication between Inquiry, 1. Evidence of Layer with off- Business Unit IT management and the Blockchain Inspection, communication Blockchain program management of a system identified as and/or between Business Unit Systems and having Blockchain dependencies. observation IT management and the Processes 2. Verify the Blockchain program management Blockchain program performed an evaluation of the impact the legacy management for a system change has on the Blockchain. system identified as 3. Obtain documentation verifying the details of having Blockchain the evaluation were documented. dependencies 4. Obtain evidence of a processed change order 2. Evaluation request to remove the Blockchain from production performed by the and through inspection, verify the request was Blockchain program completed. management 5. Obtain documentation of the back out plan and 3. Evidence that the through inspection, verify that the back out plan Blockchain was was enabled while a configuration change order removed from was processed. production 4. Change order ticket showing this request was processed and completed 5. Back out plan that was enabled Operational Integration 1. Inquire with management about the process of Inquiry, 1. The legacy system Layer with off- updating the methodology to include integration Inspection, Software Development Blockchain with Blockchain program management. and/or Lifecycle methodology Systems and 2. Obtain documentation verifying change observation for change Processes management processes have been updated with management processes the date in which these updates were made. updated with 3. Obtain evidence of the changes made to the Blockchain with the Blockchain and the date in which these changes date in which the were made. updates were made 4. Through inspection, verify that the updates 2. Evidence of the were made to the methodology prior to the changes made to the changes being made. Blockchain impacted 5. Obtain the inventory listing and through system (change order inspection, verify the listing includes functional ticket including the use of all key interfaces and legacy systems date in which the utilized by the Blockchain and that the listing is request was processed properly maintained. and completed) 3. Inventory listing with evidence of how the listing is maintained Operational Integration 1. Obtain evidence of communication between Inquiry, 1. Evidence of Layer with off- Business Unit Operations and the Blockchain Inspection, communication Blockchain program management of a business process and/or between Business Unit Systems and identified as having Blockchain dependencies. observation IT management and the Processes 2. Verify the Blockchain program management Blockchain program performed an evaluation of the impact the legacy management system change has on the Blockchain. 2. Evaluation 3. Obtain evidence verifying the details of the performed by the evaluation were documented. Blockchain program 4. Obtain evidence of a processed change order management request to remove the Blockchain from production 3. Evidence that the and through inspection, verify the request was Blockchain was completed. removed from 5. Obtain documentation of the back out plan and production through inspection, verify that the back out plan 4. Change order ticket was enabled while a configuration change order showing this request was processed. was processed 5. Back out plan that was enabled

4.6 Transactional Layer Assessment Work Program

In some embodiments, transaction layer risk category in the blockchain risk framework covers relevant risks, control objectives and descriptions, testing objectives and procedures, and reporting parameters designed to address assurance and compliance needs for the blockchain application stack/layer supporting business and transaction level processing.

The sub-risk categories, control and testing objectives, test procedures and request lists for Transactional Layer risk category are provided below in Tables 17-19.

TABLE 17 Risk Level (L, M, H) Risk Risk Risk (As Category Domain Classification Number Risk Description applicable) Transactional Smart Strategic, TL-SC1 Incorrect SC terms are not L, M, H (Business) Contracts Operational, selected for execution. (SC) Financial, Compliance/ Legal, Reputational Transactional Smart Strategic, TL-SC2 SC terms and conditions are L, M, H (Business) Contracts Operational, not inclusive of required (SC) Financial, information or standard Compliance/ terms and conditions. Legal, Reputational Transactional Smart Strategic, TL-SC3 SC is executed with wrong/ L, M, H (Business) Contracts Operational, incorrect participants or SC (SC) Financial, does not include right/correct Compliance/ participants. Legal, Reputational Transactional Smart Strategic, TL-SC4 SC is not reviewed, appraised, L, M, H (Business) Contracts Operational, and approved by appropriate (SC) Financial, participants during or before Compliance/ execution. Legal, Reputational Transactional Smart Strategic, TL-SC5 SC is completed without L, M, H (Business) Contracts Operational, execution of required terms (SC) Financial, and conditions by all Compliance/ participants. Legal, Reputational Transactional Smart Strategic, TL-SC6 Required events (e.g. L, M, H (Business) Contracts Operational, invoicing, payments, change (SC) Financial, or ownership) are not initiated Compliance/ and completed successfully Legal, during or after SC execution. Reputational Transactional Smart Strategic, TL-SC7 Privileged access is not L, M, H (Business) Contracts Operational, appropriately restricted, logged, (SC) Financial, and monitored for Smart Compliance/ Contracts, which can create a Legal, risk of unauthorized access to Reputational Smart Contracts by developers/ admins/database admins Transactional Smart Strategic, TL-SC8 End-user access is not L, M, H (Business) Contracts Operational, appropriately restricted, creating (SC) Financial, the risk of unauthorized changes/ Compliance/ deployments/executions/updates/ Legal, modifications performed for the Reputational Smart Contract and workflow Transactional Smart Strategic, TL-SC9 Smart Contract development and L, M, H (Business) Contracts Operational, change management process is (SC) Financial, not in place and followed, which Compliance/ may lead to unauthorized Legal, unilateral actions by developers Reputational to modify or remove Smart Contract functions or introduce unnecessary or insecure functions Transactional Smart Strategic, TL-SC10 Smart Contract development and L, M, H (Business) Contracts Operational, change management process is (SC) Financial, not in place and followed, which Compliance/ may lead to inappropriate and Legal, incorrect terms and conditions Reputational [e.g. timeline, pricing, resources, invoicing, settlement, etc.] defined for the Smart Contract Transactional Smart Strategic, TL-SC11 Smart Contract development and L, M, H (Business) Contracts Operational, change management process is (SC) Financial, not in place and followed, which Compliance/ may lead to inappropriate and Legal, incorrect assets and services Reputational defined for the Smart Contract Transactional Smart Strategic, TL-SC12 Smart Contract development and L, M, H (Business) Contracts Operational, change management process is (SC) Financial, not in place and followed, which Compliance/ may lead to inappropriate and Legal, incorrect participants defined for Reputational the Smart Contract Transactional Smart Strategic, TL-SC13 Smart Contract development and L, M, H (Business) Contracts Operational, change management process is (SC) Financial, not in place and followed, which Compliance/ may lead to unauthorized or Legal, incorrect Smart Contracts being Reputational introduced into the production environment Transactional Smart Strategic, TL-SC14 Unauthorized access to Blockchain L, M, H (Business) Contracts Operational, metadata or PII by unauthorized (SC) Financial, parties for development or testing Compliance/ purposes Legal, Reputational Transactional Smart Strategic, TL-SC15 Data is not retained for DLT inputs. L, M, H (Business) Contracts Operational, PKIs. or other critical systems; lack (SC) Financial, of availability limits backup and Compliance/ recovery capability Legal, Reputational Transactional Smart Strategic, TL-SC16 Input validation mechanisms for L, M, H (Business) Contracts Operational, fields and records are not in place, (SC) Financial, which may compromise the Smart Compliance/ Contract execution Legal, Reputational Transactional Smart Strategic, TL-SC17 Security mechanisms are not in L, M, H (Business) Contracts Operational, place or effective in protecting (SC) Financial, output (data), creating the risk Compliance/ of unauthorized access or changes Legal, made to output Reputational Transactional Smart Strategic, TL-SC18 Security mechanisms are not in L, M, H (Business) Contracts Operational, place or effective in protecting (SC) Financial, Smart Contracts mid their Compliance/ exposure to unauthorized parties Legal, via export and sharing Reputational functionalities Transactional Smart Strategic, TL-SC19 Mechanisms are not in place or L, M, H (Business) Contracts Operational, effective in ensuring subsequent (SC) Financial, Smart Contracts are only triggered Compliance/ when appropriate and when needed Legal, Reputational Transactional Smart Strategic, TL-SC20 Mechanisms are not in place or L, M, H (Business) Contracts Operational, effective in ensuring subsequent (SC) Financial, smart contracts, invoicing, billing Compliance/ is triggered and processed Legal, appropriately as and if needed Reputational Transactional Smart Strategic, TL-SC21 Mechanisms are not in place or L, M, H (Business) Contracts Operational, effective in ensuring subsequent (SC) Financial, movement of digital assets is Compliance/ triggered and processed Legal, appropriately as and if needed Reputational Transactional Smart Strategic, TL-SC22 Mechanisms are not in place or L, M, H (Business) Contracts Operational, effective in ensuring subsequent (SC) Financial, digital tokens are triggered and Compliance/ processed appropriately as and Legal, if needed Reputational Transactional Smart Strategic, TL-SC23 Monitoring mechanisms are not L, M, H (Business) Contracts Operational, in place for Smart Contracts, (SC) Financial, which can lead to non-detection Compliance/ of Smart Contracts not performing Legal, as intended in the production Reputational environment Transactional Smart Strategic, TL-SC24 Monitoring mechanisms are not in L, M, H (Business) Contracts Operational, place for Smart Contracts, which (SC) Financial, can create a risk of impaired Compliance/ network performance or latency Legal, Reputational Transactional Smart Strategic, TL-SC25 Monitoring mechanisms are not L, M, H (Business) Contracts Operational, in place for Smart Contracts, (SC) Financial, which can create a risk of the Compliance/ Smart Contract not being Legal, executed and completed as Reputational per defined terms Transactional Smart Strategic, TL-SC26 Monitoring mechanisms are not L, M, H (Business) Contracts Operational, in place for Smart Contracts, (SC) Financial, which can create a risk of the Compliance/ Smart Contract not being retired Legal, appropriately if necessary Reputational Transactional Smart Strategic, TL-SC27 Monitoring mcclianisms are not L, M, H (Business) Contracts Operational, in place for Smart Contracts, (SC) Financial, which can create a risk of the Compliance/ Smart Contract being deployed, Legal, modified, or changed by Reputational unauthorized participants Transactional Smart Strategic, TL-SC28 Smart Contract privacy is not L, M, H (Business) Contracts Operational, maintained throughout the (SC) Financial, Smart Contract lifecycle, Compliance/ creating tire risk of private Legal, information being divulged, Reputational shared, or disseminated Transactional Smart Strategic, TL-SC29 Interfaces are not configured L, M, H (Business) Contracts Operational, to ensure all process data (SC) Financial, transmissions within the Compliance/ blockchain are complete, Legal, accurate, and secure Reputational Transactional Smart Strategic, TL-SC30 Interfaces are not configured L, M, H (Business) Contracts Operational, to ensure all process data (SC) Financial, transmissions to off-chain Compliance/ platforms or systems are Legal, complete, accurate, and secure Reputational Transactional Smart Strategic, TL-SC31 Smart Contract arehitecture is L, M, H (Business) Contracts Operational, unable to be updated/modified (SC) Financial, and therefore docs not comply Compliance/ with new requirements or Legal, regulations or is vulnerable to Reputational newly-discovered security issues Transactional Smart Strategic, TL-SC32 Insufficient side chain safeguards L, M, H (Business) Contracts Operational, increase risk of incidents leading (SC) Financial, to loss or invalidation of assets or Compliance/ transactions related to Smart Legal, Contracts Reputational Transactional Digital Strategic, TL-DA1 Incorrectly DA onboarding may L, M, H (Business) Assets Operational, cause delay or compromise (DA) Financial, transactional level processing. Compliance/ Legal, Reputational Digital Strategic, TL-DA2 DA ownership is transferred L, M, H Assets Operational, incorrectly which may compromise (DA) Financial, transactional level processing. Compliance/ Legal, Reputational Transactional Digital Strategic, TL-DA3 DA is not managed and maintained L, M, H (Business) Assets Operational, appropriately during its lifecycle. (DA) Financial, Compliance/ Legal, Reputational Transactional Digital Strategic, TL-DA4 DA is not retired appropriately at L, M, H (Business) Assets Operational, the end of the lifecycle. (DA) Financial, Compliance/ Legal, Reputational Transactional Digital Strategic, TL-DA5 Privileged access is not L, M, H (Business) Assets Operational, appropriately restricted, logged, (DA) Financial, and monitored for Digital Assets, Compliance/ which can lead to unauthorized Legal, access Reputational Transactional Digital Strategic, TL-DA6 End-user access is not appropriately L, M, H (Business) Assets Operational, restricted, creating the risk of (DA) Financial, unauthorized changes/deployments/ Compliance/ executions/updates/modifications Legal, performed for the Digital Assets Reputational and workflow Transactional Digital Strategic, TL-DA7 Digital Assets are not configured L, M, H (Business) Assets Operational, with strong login credentials and (DA) Financial, account security protocols to Compliance/ restrict unauthorized access Legal, Reputational Transactional Digital Strategic, TL-DA8 Digital Assets are stored in an L, M, H (Business) Assets Operational, unsecure environment, and hot/ (DA) Financial, warm/cold risk factors systemic Compliance/ to each Digital Asset platform Legal, are not taken into account, Reputational creating greater risks to Digital Asset operations and security of transaction data Transactional Digital Strategic, TL-DA9 Participants are not L, M, H (Business) Assets Operational, appropriately and correctly (DA) Financial, defined which can lead to Compliance/ unauthorized access or Legal, operation of the Digital Asset Reputational Transactional Digital Strategic, TL-DA10 Digital Assets are not L, M, H (Business) Assets Operational, appropriately or correctly (DA) Financial, protected, managed, and Compliance/ monitored throughout Legal, their life cycle Reputational Transactional Digital Strategic, TL-DA11 Unauthorized or incorrect L, M, H (Business) Assets Operational, Digital Asset platforms tire (DA) Financial, introduced, compromising the Compliance/ security of the organization's Legal, Digital Asset environment Reputational Transactional Digital Strategic, TL-DA12 Digital Asset software is not L, M, H (Business) Assets Operational, updated in accordance with (DA) Financial, required updates, leading to Compliance/ version mismatching and Legal, potential compromises to Reputational security or operational limitations Transactional Digital Strategic, TL-DA13 Digital Asset management L, M, H (Business) Assets Operational, platforms are not configured (DA) Financial, with recover) procedures to Compliance/ recover loss of data and Legal, information Reputational Transactional Digital Strategic, TL-DA14 Mechanisms are not in place L, M, H (Business) Assets Operational, or effective in ensuring Digital (DA) Financial, Asset transactions are triggered Compliance/ as and if needed Legal, Reputational Transactional Digital Strategic, TL-DA15 Monitoring mechanisms are not L, M, H (Business) Assets Operational, in place for Digital Assets, which (DA) Financial, can lead to non-detection of Compliance/ Digital Assets not performing as Legal, intended in the production Reputational environment Transactional Digital Strategic, TL-DA16 Monitoring mechanisms are not L, M, H (Business) Assets Operational, in place for Digital Assets, (DA) Financial, which can create a risk of Compliance/ impaired network performance Legal, or latency Reputational Transactional Digital Strategic, TL-DA17 Monitoring mechanisms tire L, M, H (Business) Assets Operational, not in place for Digital Assets, (DA) Financial, which can create a risk of a Compliance/ Digital Asset not being utilized Legal, per defined terms Reputational Transactional Digital Strategic, TL-DA18 Monitoring mechanisms are L, M, H (Business) Assets Operational, not in place for Digital Assets, (DA) Financial, which can create a risk of the Compliance/ Digital Asset not being retired Legal, appropriately if neccssary Reputational Transactional Digital Strategic, TL-DA19 Monitoring mechanisms are L, M, H (Business) Assets Operational, not in place for Digital Assets, (DA) Financial, which can create a risk of the Compliance/ Digital Asset being utilized, Legal, modified, or changed by Reputational unauthorized participants Transactional Digital Strategic, TL-DA20 Digital Asset privacy is not L, M, H (Business) Assets Operational, maintained throughout the (DA) Financial, Digital Asset lifecycle, creating Compliance/ the risk of private information Legal, being divulged, shared, or Reputational disseminated Transactional Digital Strategic, TL-DA21 Interfaces are not configured to L, M, H (Business) Assets Operational, ensure all process data (DA) Financial, transmissions within the Compliance/ blockchain are complete, Legal, accurate, and secure Reputational Transactional Digital Strategic, TL-DA22 Interfaces are not configured to L, M, H (Business) Assets Operational, ensure all process data (DA) Financial, transmissions to off-chain Compliance/ platforms or systems are Legal, complete, accurate, and secure Reputational Transactional Digital Strategic, TL-DA23 Without price fluctuation L, M, H (Business) Assets Operational, monitoring and defined (DA) Financial, response/action plan, assets, Compliance/ contracts, tokens can be Legal, processed with incorrect Reputational value at a given point in time Transactional Digital Strategic, TL-DA24 Fluctuations in prices for L, M, H (Business) Assets Operational, commodity items like Digital (DA) Financial, Asset storage create Compliance/ opportunities for sunk costs Legal, or deadweight loss Reputational expenditures Transactional Digital Strategic, TL-DA25 Digital Assets within the L, M, H (Business) Assets Operational, organization are not linked (DA) Financial, with soft or intangible assets Compliance/ (i.e. human resources) Legal, causing lack of operational Reputational alignment across the organization Transactional Digital Strategic, TL-DA26 Digital Assets within the L, M, H (Business) Assets Operational, organization are not linked (DA) Financial, with other real world assets Compliance/ (i.e. real estate, property, Legal, etc.) causing lack of Reputational operational alignment across the organization Transactional Digital Strategic, TL-DA27 The existence of physical/ L, M, H (Business) Assets Operational, logical assets is not tracked (DA) Financial, or managed on a regular Compliance/ basis, causing inaccurate Legal, and incomplete Reputational representation of physical assets in a digital form Transactional Digital Strategic, TL-DA28 The organization's legacy L, M, H (Business) Assets Operational, system accounts are not (DA) Financial, linked with DLT associated Compliance/ Digital Assets, causing lack Legal, of operational alignment Reputational across the organization Transactional Digital Strategic, TL-DT1 Participants are not on- L, M, H (Business) Tokens Operational, boarded for DC transactions. (DT) Financial, Compliance/ Legal, Reputational Transactional Digital Strategic, TL-DT2 Account balance cannot L, M, H (Business) Tokens Operational, support DC transaction (DT) Financial, request for processing. Compliance/ Legal, Reputational Transactional Digital Strategic, TL-DT3 DC-in requests are not L, M, H (Business) Tokens Operational, processed correctly. (DT) Financial, Compliance/ Legal, Reputational Transactional Digital Strategic, TL-DT4 DC-out requests are not L, M, H (Business) Tokens Operational, processed correctly. (DT) Financial, Compliance/ Legal, Reputational Transactional Digital Strategic, TL-DT5 DC duplicate transactions L, M, H (Business) Tokens Operational, are processed. (DT) Financial, Compliance/ Legal, Reputational Transactional Digital Strategic, TL-DT6 DC transactions are L, M, H (Business) Tokens Operational, approved. (DT) Financial, Compliance/ Legal, Reputational Transactional Digital Strategic, TL-DT7 DC transaction information L, M, H (Business) Tokens Operational, is missing which may (DT) Financial, compromise transaction Compliance/ processing. Legal, Reputational Transactional Digital Strategic, TL-DT8 Address is not generated or L, M, H (Business) Tokens Operational, shared with participants for (DT) Financial, DC transactions. Compliance/ Legal, Reputational Transactional Digital Strategic, TL-DT9 Cancelled or failed L, M, H (Business) Tokens Operational, transactions are not tracked (DT) Financial, or processed correctly. Compliance/ Legal, Reputational Transactional Digital Strategic, TL-DT10 DC is not moved from one L, M, H (Business) Tokens Operational, participant to the other (e.g. (DT) Financial, payor and payee) correctly Compliance/ and in a timely manner. Legal, Reputational Transactional Digital Strategic, TL-DT11 DC is not evaluated correctly L, M, H (Business) Tokens Operational, relative to underlying asset or (DT) Financial, currency. Compliance/ Legal, Reputational Transactional Digital Strategic, TL-DT12 Privileged access is not L, M, H (Business) Tokens Operational, appropriately restricted, (DT) Financial, logged, and monitored for Compliance/ Digital Tokens, which can Legal, lead to unauthorized access Reputational Transactional Digital Strategic, TL-DT13 End-user access is not L, M, H (Business) Tokens Operational, appropriately restricted, (DT) Financial, which can lead to Compliance/ unauthorized changes/ Legal, updates/modifications Reputational performed for the Digital Tokens and workflow Transactional Digital Strategic, TL-DT14 Digital Tokens are not L, M, H (Business) Tokens Operational, configured with strong (DT) Financial, login credentials and Compliance/ account security protocols Legal, to restrict unauthorized Reputational access Transactional Digital Strategic, TL-DT15 Digital Token development L, M, H (Business) Tokens Operational, and change management (DT) Financial, process is not in place and Compliance/ followed, which may lead to Legal, inappropriate and incorrect Reputational participants defined for authorized use of Digital Tokens Transactional Digital Strategic, TL-DT16 Digital Tokens are not L, M, H (Business) Tokens Operational, appropriately or correctly (DT) Financial, protected, managed, and Compliance/ monitored throughout their Legal, life Reputational Transactional Digital Strategic, TL-DT17 Digital Tokens are not L, M, H (Business) Tokens Operational, monitored appropriately (DT) Financial, throughout their life cycle Compliance/ causing inaccurate records Legal, for when tokens were created, Reputational converted, updated, and retired Transactional Digital Strategic, TL-DT18 Digital Token development and L, M, H (Business) Tokens Operational, change management process is (DT) Financial, not in place and followed, which Compliance/ may lead to unauthorized or Legal, incorrect Digital Tokens being Reputational introduced into the operational environment Transactional Digital Strategic, TL-DT19 Lack of a clearly defined Digital L, M, H (Business) Tokens Operational, Token platform can potentially (DT) Financial, endanger the organization's Compliance/ transactional data or create Legal, unauthorized operational Reputational redundancies Transactional Digital Strategic, TL-DT20 Digital Token platforms are not L, M, H (Business) Tokens Operational, configured with recovery (DT) Financial, procedures to recover loss of Compliance/ data and information Legal, Reputational TL-DT21 Ownership of assets linked to L, M, H Transactional Digital Strategic, Digital Tokens is not defined (Business) Tokens Operational, or managed by the organization (DT) Financial, Compliance/ Legal, Reputational Transactional Digital Strategic, TL-DT22 Data is not retained for DLT L, M, H (Business) Tokens Operational, inputs, PKIs, or other critical (DT) Financial, systems; lack of availability Compliance/ limits backup and recovery Legal, capability Reputational Transactional Digital Strategic, TL-DT23 Mechanisms are not in place L, M, H (Business) Tokens Operational, or effective in ensuring Digital (DT) Financial, Token transactions are triggered Compliance/ as and if needed Legal, Reputational Transactional Digital Strategic, TL-DT24 Digital Tokens are not L, M, H (Business) Tokens Operational, monitored to ensure tokens are (DT) Financial, utilized appropriately for Compliance/ authorized transactions or Legal, operations Reputational Transactional Digital Strategic, TL-DT25 Digital Token ownership and L, M, H (Business) Tokens Operational, management of ownership is (DT) Financial, not monitored appropriately Compliance/ Legal, Reputational Transactional Digital Strategic, TL-DT26 The DLT and off-chain ledger L, M, H (Business) Tokens Operational, or accounting mechanisms (DT) Financial, are not monitored, Compliance/ compromising the ability to Legal, accurately track usage of Reputational tokens during normal operations and transactions Transactional Digital Strategic, TL-DT27 Monitoring mechanisms are L, M, H (Business) Tokens Operational, not in place for Digital Tokens, (DT) Financial, which can create a risk of Digital Compliance/ Tokens being utilized, modified, Legal, or changed by unauthorized Reputational participants Transactional Digital Strategic, TL-DT28 Interfaces are not configured to L, M, H (Business) Tokens Operational, ensure all process data (DT) Financial, transmissions within the Compliance/ blockchain are complete, accurate, Legal, and secure Reputational Transactional Digital Strategic, TL-DT29 Interfaces are not configured to L, M, H (Business) Tokens Operational, ensure all process data (DT) Financial, transmissions to off-chain Compliance/ platforms or systems are complete, Legal, accurate, and secure Reputational Transactional Digital Strategic, TL-DT30 Without price fluctuation L, M, H (Business) Tokens Operational, monitoring and defined response/ (DT) Financial, action plan, tokens, contracts, Compliance/ tokens can be processed with Legal, incorrect value at a given point Reputational in time Transactional Digital Strategic, TL-DT31 Fluctuations in prices for L, M, H (Business) Tokens Operational, commodity items like Digital (DT) Financial, Token storage create opportunities Compliance/ for sunk costs or deadweight loss Legal, expenditures Reputational Transactional Digital Strategic, TL-DT32 The existence of digital tokens or L, M, H (Business) Tokens Operational, funds used for blockchain (DT) Financial, transactions are not validated Compliance/ Legal, Reputational Transactional Digital Strategic, TL-DT33 Digital tokens are not configured L, M, H (Business) Tokens Operational, with strong login credentials and (DT) Financial, account security protocols to Compliance/ restrict unauthorized access Legal, Reputational Transactional Digital Strategic, TL-DW01 Privileged access is not L, M, H (Business) Wallets Operational, appropriately restricted, logged, (DW) Financial, and monitored for Digital Wallets, Compliance/ which can lead to unauthorized Legal, access to Digital Wallets Reputational Transactional Digital Strategic, TL-DW02 End-user access is not L, M, H (Business) Wallets Operational, appropriately restricted, creating (DW) Financial, the risk of unauthorized changes/ Compliance/ deployments/executions/updates/ Legal, modifications performed for Reputational Digital Wallets and workflow Transactional Digital Strategic, TL-DW03 Digital Wallets are not configured L, M, H (Business) Wallets Operational, with strong login credentials and (DW) Financial, account security protocols to Compliance/ restrict unauthorized access Legal, Reputational Transactional Digital Strategic, TL-DW04 Digital Wallets, ledgers, and L, M, H (Business) Wallets Operational, access points are stored in an (DW) Financial, insecure environment, and hot/ Compliance/ warm/cold risk factors sy stemic Legal, to each wallet platform are not Reputational taken into account, creating greater risks to Digital Wallet operations and security of transaction data Transactional Digital Strategic, TL-DW05 Digital Wallet development L, M, H (Business) Wallets Operational, and change management (DW) Financial, process is not in place and Compliance/ followed, which may lead to Legal, inappropriate and incorrect Reputational participants defined for the Digital Wallet Transactional Digital Strategic, TL-DW06 Digital Wallet development and L, M, H (Business) Wallets Operational, change management process is (DW) Financial, not in place and followed, which Compliance/ may lead to unauthorized or Legal, incorrect Digital Wallets being Reputational introduced into the environment Transactional Digital Strategic, TL-DW07 Digital Wallet software is not L, M, H (Business) Wallets Operational, updated in accordance w ith (DW) Financial, required updates, leading to Compliance/ version mismatching and Legal, potential compromises to Reputational security or operational limitations Transactional Digital Strategic, TL-DW08 Lack of a clearly defined Digital L, M, H (Business) Wallets Operational, Wallet platform can potentially (DW) Financial, endanger the organization's Compliance/ transactional data, create Legal, unauthorized operational Reputational redundancies, or inhibit consistent and effective risk management of specific Digital Wallet platforms (i.e. software, hardware, ledger, etc.) Transactional Digital Strategic, TL-DW09 Digital Wallet platforms are not L, M, H (Business) Wallets Operational, configured with recovery (DW) Financial, procedures to recover lost data Compliance/ and information Legal, Reputational Transactional Digital Strategic, TL-DW10 Data is not retained for DLT L, M, H (Business) Wallets Operational, inputs, PKIs, or other critical (DW) Financial, systems, lack of availability limits Compliance/ backup and recovery capability Legal, Reputational Transactional Digital Strategic, TL-DW11 Input validation mechanisms for L, M, H (Business) Wallets Operational, fields and records are not in place, (DW) Financial, which may compromise the Compliance/ Digital Wallet's operations Legal, Reputational Transactional Digital Strategic, TL-DW12 Security mechanisms are not in L, M, H (Business) Wallets Operational, place or effective in protecting (DW) Financial, output (data), creating the risk of Compliance/ unauthorized access or changes Legal, made to output Reputational Transactional Digital Strategic, TL-DW13 Security mechanisms are not in L, M, H (Business) Wallets Operational, place or effective in protecting (DW) Financial, Digital Wallets and their exposure Compliance/ to unauthorized parties via export Legal, and sharing functionalities Reputational Transactional Digital Strategic, TL-DW14 Mechanisms are not in place or L, M, H (Business) Wallets Operational, effective in ensuring Digital Wallet (DW) Financial, transactions are only triggered Compliance/ when appropriate and when needed Legal, Reputational Transactional Digital Strategic, TL-DW15 Mechanisms are not in place or L, M, H (Business) Wallets Operational, effective in ensuring off-chain (DW) Financial, invoicing and billing is triggered Compliance/ and processed by authorized Legal, participants appropriately as and Reputational if needed Transactional Digital Strategic, TL-DW16 Mechanisms are not in place or L, M, H (Business) Wallets Operational, effective in ensuring digital token (DW) Financial, transactions are triggered and Compliance/ processed appropriately as and Legal, if needed Reputational Transactional Digital Strategic, TL-DW17 Mechanisms are not in place or L, M, H (Business) Wallets Operational, effective in ensuring subsequent (DW) Financial, Digital Wallet transactions are Compliance/ triggered and processed by Legal, authorized participants and Reputational appropriately as and if needed Transactional Digital Strategic, TL-DW18 Monitoring meclianisms are not L, M, H (Business) Wallets Operational, in place for Digital Wallets, (DW) Financial, which can lead to non-detection Compliance/ of Digital Wallets not Legal, performing as intended in the Reputational environment Transactional Digital Strategic, TL-DW19 Monitoring mechanisms are L, M, H (Business) Wallets Operational, not in place for Digital Wallets, (DW) Financial, which can create a risk of Compliance/ impaired network performance Legal, or latency Reputational Transactional Digital Strategic, TL-DW20 Mechanisms are not in place L, M, H (Business) Wallets Operational, to monitor Digital Wallet (DW) Financial, transactions and ensure Compliance/ transactions are executed Legal, per defined terms Reputational Transactional Digital Strategic, TL-DW21 Monitoring mechanisms are L, M, H (Business) Wallets Operational, not in place for Digital Wallets, (DW) Financial, which can create a risk of the Compliance/ Digital Wallet not being retired Legal, appropriately if necessary Reputational Transactional Digital Strategic, TL-DW22 Monitoring mechanisms are L, M, H (Business) Wallets Operational, not in place for Digital Wallets, (DW) Financial, which can create a risk of the Compliance/ Digital Wallet being utilized, Legal, modified, or changed by Reputational unauthorized participants Transactional Digital Strategic, TL-DW23 Digital Wallet privacy is not L, M, H (Business) Wallets Operational, maintained throughout the (DW) Financial, Digital Wallet lifecycle, Compliance/ creating the risk of private Legal, information being divulged, Reputational shared, or disseminated Transactional Digital Strategic, TL-DW24 Interfaces are not configured L, M, H (Business) Wallets Operational, to ensure all process data (DW) Financial, transmissions within the Compliance/ blockchain are complete, Legal, accurate, and secure Reputational Transactional Digital Strategic, TL-DW25 Interfaces are not configured L, M, H (Business) Wallets Operational, to ensure all process data (DW) Financial, transmissions to off-chain Compliance/ platforms or systems are Legal, complete, accurate, and secure Reputational Transactional Digital Strategic, TL-DW26 Mechanisms are not in place L, M, H (Business) Wallets Operational, or effective in ensuring Digital (DW) Financial, Wallets are configured with Compliance/ appropriate transaction Legal, thresholds to prevent failed Reputational detection of transferred funds Transactional Digital Strategic, TL-DW27 Security mechanisms are not L, M, H (Business) Wallets Operational, in place for Digital Wallets, (DW) Financial, compromising private keys or Compliance/ PKIs, which may result in Legal, breaches of Digital Wallet security or risk of unauthorized access to assets stored on the wallet platform Transactional Digital Strategic, TL-DW28 The organization's legacy L, M, H (Business) Wallets Operational, system accounts are not linked (DW) Financial, with PKIs or DLTs associated Compliance/ with the Digital Wallet, causing Legal, lack of operational alignment Reputational across the organization Transactional Clearing Strategic, TL-CS1 Movement of underlying asset L, M, H (Business) and Operational, or currency is not synchronized Settle- Financial, with books of records. ment Compliance/ Legal, Reputational Transactional Buisness Strategic, TL-BU1 Transactions are not approved. L, M, H (Business) Use case Operational, transactions Financial, Compliance/ Legal, Reputational Transactional Buisness Strategic, TL-BU2 Transactions are not processed L, M, H (Business) Use case Operational, accurately, completely or within transactions Financial, approved guidelines. Compliance/ Legal, Reputational

TABLE 18 In-scope/ Out-of- Scope (TBD—As Risk per Category Domain Control/Test Objective Control Description engagement) Transactional Smart Control(s) is in place to ensure correct Inquire management of the In-scope (Business) Contracts template is used for SC execution. control activities that are (SC) in place to meet applicable risks and relevant control objectives. Transactional Smart Control(s) is in place to ensure that required Inquire management of the In-scope (Business) Contracts information or standard terms and conditions control activities that are (SC) are included in the SC before execution. in place to meet applicable risks and relevant control objectives. Transactional Smart Control(s) is in place to ensure that required Inquire management of the In-scope (Business) Contracts andcorrect participants associated with control activities that are (SC) the SC before execution. in place to meet applicable risks and relevant control objectives. Transactional Smart Control(s) is in place to ensure that SC is Inquire management of the In-scope (Business) Contracts reviewed, appraised, and approved by control activities that are (SC) appropriate participants. in place to meet applicable risks and relevant control objectives. Transactional Smart Control(s) is in place to ensure that SC is Inquire management of the In-scope (Business) Contracts executed after terms and conditions are control activities that are (SC) met by all participants. in place to meet applicable risks and relevant control objectives. Transactional Smart Control(s) is in place to ensure that required Inquire management of the In-scope (Business) Contracts events (e.g. invoicing, payments, change or control activities that are (SC) ownership) are initiated and completed in place to meet applicable successfully during or after SC execution. risks and relevant control Upon consensus, smart contracts auto- objectives. matically executes the exchange of position and cash in a complete, accurate and timely manner. Transactional Digital Control(s) is in place to ensure that DAs are Inquire management of the In-scope (Business) Assets classified and created correctly and control activities that are (DA) successfully for transactional level in place to meet applicable processing. risks and relevant control objectives. Digital Control(s) is in place to ensure that DA Inquire management of the In-scope Assets ownership is transferred to the right/correct control activities that are (DA) participants in a timely manner. in place to meet applicable risks and relevant control objectives. Transactional Digital Control(s) is in place to ensure that DA is Inquire management of the In-scope (Business) Assets managed and maintained (e.g. classification, control activities that are (DA) valuation, and handovers) appropriately in place to meet applicable throughout the lifecycle. risks and relevant control objectives. Transactional Digital Control(s) is in place to ensure that DA is Inquire management of the In-scope (Business) Assets retired appropriately at the end of the control activities that are (DA) lifecycle. in place to meet applicable risks and relevant control objectives. Transactional Digital Control(s) is in place to ensure that valid Inquire management of the In-scope (Business) Currency participants are on-boarded and assigned control activities that are (DC) with a digital wallet for DC transactions. in place to meet applicable risks and relevant control objectives. Transactional Digital Control(s) is in place to ensure that a payor Inquire management of the In-scope (Business) Currency account balance is checked and verified to control activities that are (DC) validate that sufficient DC is available before in place to meet applicable the transaction is processed or completed. risks and relevant control objectives. Transactional Digital Control(s) is in place to ensure that DC-in Inquire management of the In-scope (Business) Currency (Cash-in) requests are processed completely control activities that are (DC) and accurately. in place to meet applicable risks and relevant control objectives. Transactional Digital Control(s) is in place to ensure that DC-out Inquire management of the In-scope (Business) Currency (Cash-out) requests are processed completely control activities that are (DC) and accurately. in place to meet applicable risks and relevant control objectives. Transactional Digital Control(s) is in place to ensure that a Inquire management of the In-scope (Business) Currency duplicate DC transactions are not processed. control activities that are (DC) in place to meet applicable risks and relevant control objectives. Transactional Digital Control(s) is in place to ensure that a DC Inquire management of the In-scope (Business) Currency transactions are approved appropriately for control activities that are (DC) processing. in place to meet applicable risks and relevant control objectives. Transactional Digital Control(s) is in place to ensure that a DC Inquire management of the In-scope (Business) Currency transactions contain required information for control activities that are (DC) processing. in place to meet applicable risks and relevant control objectives. Transactional Digital Control(s) is in place to ensure that a valid Inquire management of the In-scope (Business) Currency unique address is generated and shared with control activities that are (DC) appropriate participants in safe and secure in place to meet applicable manner for DC transactions processing. risks and relevant control objectives. Transactional Digital Control(s) is in place to ensure that cancelled Inquire management of the In-scope (Business) Currency and failed transactions are monitored, control activities that are (DC) processed and recorded in the books in place to meet applicable accurately. risks and relevant control objectives. Transactional Digital Control(s) is in place to ensure that DC is Inquire management of the In-scope (Business) Currency moved from one participant to the other (e.g. control activities that are (DC) payee and payor) correctly and in a timely in place to meet applicable manner. Also, the movement of DC is risks and relevant control recorded in the books of records accurately. objectives. Transactional Digital Control(s) is in place to ensure that DC is Inquire management of the In-scope (Business) Currency evaluated correctly relative to underlying control activities that are (DC) asset or currency in a timely manner. in place to meet applicable risks and relevant control objectives. Transactional Clearing Control(s) is in place to ensure that books Inquire management of the In-scope (Business) and of records are updated when the underlying control activities that are Settlement asset or currency is processed. Reconcil- in place to meet applicable iation and verification between books of risks and relevant control records and underlying asset or currency objectives. position is performed to validate integrity, accuracy and completeness of transactional and business information. Control(s) is in place to ensure that trades/transactions processing meet the following financial statements assertion requirements: 1—Rights and obligations 2—Completeness, accuracy, cutoff 3—Existence 4—Valuation Transactional Business Control(s) is in place to ensure that business Inquire management of the In-scope (Business) Use case transactions are authorized and executed in control activities that are transactions accordance with approved guidelines. in place to meet applicable risks and relevant control objectives. Transactional Business Control(s) is in place to ensure that trades/ Inquire management of the In-scope (Business) Use case transactions meet the following financial control activities that are transactions statements assertion requirements: in place to meet applicable 1—Rights and obligations risks and relevant control 2—Completeness, accuracy, cutoff objectives. 3—Existence 4—Valuation

TABLE 19 Re- Test Type quest Risk (TBD—As List Category Domain Test Procedure (#) per engagement) (#) Transactional Smart Based on the inquiry of the Inquiry, Inspection, (Business) Contracts management regarding the control observation, and/or (SC) activities in place assessment Automated results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Transactional Smart Based on the inquiry of the Inquiry, Inspection, (Business) Contracts management regarding the control observation, and/or (SC) activities in place assessment Automated results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Transactional Smart Based on the inquiry of the Inquiry, Inspection, (Business) Contracts management regarding the control observation, and/or (SC) activities in place assessment Automated results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Transactional Smart Based on the inquiry of the Inquiry, Inspection, (Business) Contracts management regarding the control observation, and/or (SC) activities in place assessment Automated results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Transactional Smart Based on the inquiry of the Inquiry, Inspection, (Business) Contracts management regarding the control observation, and/or (SC) activities in place assessment Automated results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Transactional Smart Based on the inquiry of the Inquiry, Inspection, (Business) Contracts management regarding the control observation, and/or (SC) activities in place assessment Automated results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Transactional Digital Based on the inquiry of the Inquiry, Inspection, (Business) Assets management regarding the control observation, and/or (DA) activities in place assessment Automated results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Digital Based on the inquiry of the Inquiry, Inspection, Assets management regarding the control observation, and/or (DA) activities in place assessment Automated results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Transactional Digital Based on the inquiry of the Inquiry, Inspection, (Business) Assets management regarding the control observation, and/or (DA) activities in place assessment Automated results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Transactional Digital Based on the inquiry of the Inquiry, Inspection, (Business) Assets management regarding the control observation, and/or (DA) activities in place assessment Automated results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Transactional Digital Based on the inquiry of the Inquiry, Inspection, (Business) Currency management regarding the control observation, and/or (DC) activities in place assessment Automated results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Transactional Digital Based on the inquiry of the Inquiry, Inspection, (Business) Currency management regarding the control observation, and/or (DC) activities in place assessment Automated results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Transactional Digital Based on the inquiry of the Inquiry, Inspection, (Business) Currency management regarding the control observation, and/or (DC) activities in place assessment Automated results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Transactional Digital Based on the inquiry of the Inquiry, Inspection, (Business) Currency management regarding the control observation, and/or (DC) activities in place assessment Automated results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Transactional Digital Based on the inquiry of the Inquiry, Inspection, (Business) Currency management regarding the control observation, and/or (DC) activities in place assessment Automated results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Transactional Digital Based on the inquiry of the Inquiry, Inspection, (Business) Currency management regarding the control observation, and/or (DC) activities in place assessment Automated results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Transactional Digital Based on the inquiry of the Inquiry, Inspection, (Business) Currency management regarding the control observation, and/or (DC) activities in place assessment Automated results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Transactional Digital Based on the inquiry of the Inquiry, Inspection, (Business) Currency management regarding the control observation, and/or (DC) activities in place assessment Automated results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Transactional Digital Based on the inquiry of the Inquiry, Inspection, (Business) Currency management regarding the control observation, and/or (DC) activities in place assessment Automated results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Transactional Digital Based on the inquiry of the Inquiry, Inspection, (Business) Currency management regarding the control observation, and/or (DC) activities in place assessment Automated results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Transactional Digital Based on the inquiry of the Inquiry, Inspection, (Business) Currency management regarding the control observation, and/or (DC) activities in place assessment Automated results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Transactional Clearing Based on the inquiry of the Inquiry, Inspection, (Business) and management regarding the control observation, and/or Settle- activities in place assessment Automated ment results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Transactional Business Based on the inquiry of the Inquiry, Inspection, (Business) Use case management regarding the control observation, and/or transac- activities in place assessment Automated tions results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software Transactional Business Based on the inquiry of the Inquiry, Inspection, (Business) Use case management regarding the control observation, and/or transac- activities in place assessment Automated tions results test procedures will be designed and data parameters will be identified to configure and operationalize the Blockchain Auditing software

In one or more embodiments, the blockchain risk framework is designed to produce testing procedures that align with a technology stack associated with a blockchain. FIG. 5A illustrates a correspondence between the testing procedures produced by a risk framework and a technology stack of a blockchain system according to examples of the disclosure. In FIG. 5A, a block chain use-case technology stack can include multiple technology stacks that are integrated together to form the overall blockchain computing system. For instance in the example of FIG. 6, a block-chain use-case technology stack 600 can include an application layer 502, encryption (cryptography) layer 506, a permissioned or unpermissioned network layer (i.e., operational layer) 508, a shared data layer 510, a commercial API layer 512, and an overlay network layer 514.

In one or more examples, an application layer 502 can include decentralized applications (i.e., a digital application or program) that can be run by many users or nodes on a decentralized network with consensus and other trustless protocols. They can be designed to avoid any single point of failure. The applications in the application layer provide workflow and processing logic to execute transactional activity using shared communications protocols and interface methods used by hosts in a communications network.

In one or more examples, an encryption (cryptography) layer 506 can include cryptography used to cipher (encrypt) and de-cipher (decrypt) information by using a mathematical function or algorithm. Encryption can refer to the process of transforming information so it is unintelligible/inaccessible/unreadable to anyone but the intended recipient. Decryption is the process of transforming encrypted information so that it is intelligible/accessible/readable again.

In one or more examples, a permissioned or unpermissioned network layer 508 can refer to both permissioned networks and unpermissioned networks. Unpermissioned networks can refer to an open blockchain network that anyone can join and participate in. The community operates and administers the blockchain, and one or more participants can provide consensus. Any user can join a permissionless network, i.e., exchanging digital currency on a public currency exchange. A permissioned network refers to a blockchain model that requires permission to join, read, write to, operate and administer. Multiple participants administer the blockchain under consortium or group leadership. There may be restrictions on how participants can contribute to the system state or consensus of transactions. In one or more examples network layer 508 can also include private blockchains. In a private blockchain, only a centralized entity or single participant has permission to write to the blockchain. Platform architects can decide how to assign permissions.

In one or more examples, shared data layer 510 can include organized collections of data that are stored and accessed electronically. In one or more example a commercial API layer 512 can include elements dealing with an interface in software that can act as a shared boundary across which two or more separate components of a computer system exchange information. The exchange can be between software, computer hardware, peripheral devices, humans and combinations of these. Finally, in one or more examples, an overlay network layer 514 includes different types of LAN and WAN networks that are used to access the blockchain system. The network layer provides the means of transferring variable-length network packets from a source to a destination host via one or more networks.

One or more of the risk categories described above can correspond to one or more layers of the stack 500. For instance, in the example of FIG. 5A, transaction layer risks 518 can correspond to the application layer 502 of the stack 500. This can mean that test procedures created in response to the “transactional layer” risk framework can create test procedures that validate the application layer of the blockchain use-case stack 500. Likewise, blockchain architecture layer risks 514 can generate test procedures that test and validate the decentralized protocols layer 504, and the encryption layer 506. The operation layer risks 520 can generate tests that can validate and test permissioned network layer 508. Finally the infrastructure layer risks 516 of the risk framework can create test procedures that can validate and test shared data layer 510, commercial API layer 512, and overlay network 514.

FIG. 5B illustrates sub-categories corresponding to each risk framework category according to examples of the disclosure. As illustrated in FIG. 5B, each category of risk can include one or more subcategories. For instance, the governance and oversight risk category 530 can include one or more sub-categories including (but not limited to): business objectives, program sponsorship, leadership commitment, MIS and metrics, program management, operational and capital expenditure oversight, and project management. The cyber security risk category 530 can include one or more sub-categories including (but not limited to): cloud security, data security, data privacy, penetration testing, programming security, network security, patch vulnerability, threat detection, and threat response. The infrastructure risk category 534 can include one or more sub-categories including (but not limited to): servers and databases configuration, ITGCs, business continuity and disaster recovery, and IT asset management. The transactional layer risk category 536 can include one or more sub-categories including (but not limited to): smart contracts, digital assets, digital currency, cleaning and settlement, business use and case transactions. The operation layer risk category 538 can include one or more sub-categories including (but not limited to): permissioned network management, participant over boarding and off-boarding, application layer, blockchain consensus program management, and integration with off-blockchain systems and processes. Finally the blockchain architecture risk category 540 can include one or more sub-categories including (but not limited to): blockchain platform and protocol configuration, hardware security modules, signature management, cryptography, scalability, and availability.

In some embodiments, the results (i.e. testing procedures and parameters) of an assessment performed using the blockchain risk framework can be used to consolidate the audit and compliance activities into categories by nature of activity at the transaction layer and embed them into an validating software/tool. By drawing data from the underlying blockchain ledger as well as from other up and down stream systems affecting the use case, any and all necessary audit or assurance based procedures can be fully automate and active transparency for them on a real time basis (or some other cadence if preferred) can be provided to the practitioner.

As illustrated in the discussion above, the risk framework can provide a user interface that translates a user's blockchain auditing preferences into tangible tests and procedures that are then used to perform real-time continuous monitoring of the block chain system. FIG. 6 illustrates an exemplary process for generating blockchain test procedures according to examples of the disclosure. The process 600 described with respect to FIG. 6 can be performed on a computing system that includes a display and devices that are configured to accept input from a user such as a keyboard, touchpad, mouse, etc.

The process can begin at step 602, wherein the user is presented with the risk framework and is prompted by the risk framework to specify a risk level associated with each risk category and sub-category as described above. Once the user specifies the risk levels, the process can move to step 604 wherein the user can be presented with a series of controls of the blockchain that relate to the risks identified in step 602 (as described above). When presented with the series of controls, the user can then be prompted by the risk framework to input which controls are to be in-scope of the assessment, and which ones are to be considered out of scope as described above.

Once the user indicates which controls are in scope versus out of scope at step 604, the process can move to step 606, wherein the risk framework generates one or more test procedures based on the user's inputs into the risk framework. Once the tests are generated at step 606, the process can move to step 608 wherein the test procedures are transmitted to an external user. In one or more examples, transmitting the test procedures can include generating a planning file that can be used by a validation software (like the one described with respect to FIG. 4) to perform real-time and continuous validation of a blockchain.

FIG. 7 illustrates an example of a computing device in accordance with one embodiment. Device 700 can be a host computer connected to a network. Device 700 can be a client computer or a server. As shown in FIG. 7, device 700 can be any suitable type of microprocessor-based device, such as a personal computer, workstation, server, or handheld computing device (portable electronic device) such as a phone or tablet. The device can include, for example, one or more of processor 710, input device 720, output device 730, storage 740, and communication device 760. Input device 720 and output device 730 can generally correspond to those described above and can either be connectable or integrated with the computer.

Input device 720 can be any suitable device that provides input, such as a touch screen, keyboard or keypad, mouse, or voice-recognition device. Output device 730 can be any suitable device that provides output, such as a touch screen, haptics device, or speaker.

Storage 740 can be any suitable device that provides storage, such as an electrical, magnetic, or optical memory, including a RAM, cache, hard drive, or removable storage disk. Communication device 760 can include any suitable device capable of transmitting and receiving signals over a network, such as a network interface chip or device. The components of the computer can be connected in any suitable manner, such as via a physical bus or wirelessly.

Software 750, which can be stored in storage 740 and executed by processor 710, can include, for example, the programming that embodies the functionality of the present disclosure (e.g., as embodied in the devices as described above).

Software 750 can also be stored and/or transported within any non-transitory computer-readable storage medium for use by or in connection with an instruction execution system, apparatus, or device, such as those described above, that can fetch instructions associated with the software from the instruction execution system, apparatus, or device and execute the instructions. In the context of this disclosure, a computer-readable storage medium can be any medium, such as storage 740, that can contain or store programming for use by or in connection with an instruction execution system, apparatus, or device.

Software 750 can also be propagated within any transport medium for use by or in connection with an instruction execution system, apparatus, or device, such as those described above, that can fetch instructions associated with the software from the instruction execution system, apparatus, or device and execute the instructions. In the context of this disclosure, a transport medium can be any medium that can communicate, propagate, or transport programming for use by or in connection with an instruction execution system, apparatus, or device. The transport readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, or infrared wired or wireless propagation medium.

Device 700 may be connected to a network, which can be any suitable type of interconnected communication system. The network can implement any suitable communications protocol and can be secured by any suitable security protocol. The network can comprise network links of any suitable arrangement that can implement the transmission and reception of network signals, such as wireless network connections, T1 or T3 lines, cable networks, DSL, or telephone lines.

Device 700 can implement any operating system suitable for operating on the network. Software 750 can be written in any suitable programming language, such as C, C++, Java, or Python. In various embodiments, application software embodying the functionality of the present disclosure can be deployed in different configurations, such as in a client/server arrangement or through a Web browser as a Web-based application or Web service, for example.

The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the techniques and their practical applications. Others skilled in the art are thereby enabled to best utilize the techniques and various embodiments with various modifications as are suited to the particular use contemplated.

Although the disclosure and examples have been fully described with reference to the accompanying figures, it is to be noted that various changes and modifications will become apparent to those skilled in the art. Such changes and modifications are to be understood as being included within the scope of the disclosure and examples as defined by the claims.

This application discloses several numerical ranges in the text and figures. The numerical ranges disclosed inherently support any rage or value within the disclosed numerical ranges, including the endpoints, even though a precise range limitation is not stated verbatim in the specification because this disclosure can be practiced throughout the disclosed numerical ranges.

The above description is presented to enable a person skilled in the art to make and use the disclosure and is provided in the context of a particular application and its requirements. Various modifications to the preferred embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the disclosure. Thus, this disclosure is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein. Finally, the entire disclosure of the patents and publications referred in this application are hereby incorporated herein by reference. 

What is claimed is:
 1. A method comprising: at an electronic device with a display and an interface configured to accept one or more inputs from a user of the electronic device: displaying one or more risk categories to a user using the display; prompting the user to input one or more risk levels via the interface, wherein each risk level on the one or more risk levels corresponds to the one or more risk categories displayed; displaying one or more test objectives or controls via the display; prompting the user to indicate which of the one or more test objectives are to be evaluated via the displaying; and wherein in response to the user providing one or more risk levels and one or more test objectives, the electronic device is caused to: convert the one or more user provided risk levels and one or more test objectives into one or more test procedures to be implemented by a real-time distributed ledger-based computing system validation tool; and transmit the generated one or more test procedures to an external user.
 2. The method of claim 1, wherein the one or more risk categories are selected from a group consisting of government and oversight, cyber security, infrastructure layer, architecture layer, operational layer, and transaction layer.
 3. The method of claim 2, wherein if the user selects a transaction layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate an application layer of a distributed ledger-based computing system technology stack.
 4. The method of claim 2, wherein if the user selects a blockchain architecture risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a decentralized protocols and encryption layer of a distributed ledger-based computing system technology stack.
 5. The method of claim 2, wherein if the user selects an operational layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a permissioned network layer of a distributed ledger-based computing system technology stack.
 6. The method of claim 2, wherein if the user selects an infrastructure layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a shared data layer of a distributed ledger-based computing system technology stack.
 7. The method of claim 6, wherein if the user selects an infrastructure layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a commercial API layer of a distributed ledger-based computing system technology stack.
 8. The method of claim 7, wherein if the user selects an infrastructure layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate overlay network layer of a distributed ledger-based computing system technology stack.
 9. The method of claim 1, wherein transmitting the generated one or more test procedures to an external user includes transmitting the generated one or more test procedures to a real-time continuous distributed ledger-based computing system auditing tool.
 10. The method of claim 9, wherein transmitting the generated one or more test procedures includes writing the generated one or more test procedures to a planning file, and transmitting the planning file to the real-time continuous distributed ledger-based computing system auditing tool.
 11. A computing system, comprising: a display; a user interface configured to receive inputs from a user of the system; a memory; one or more processors; and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs when executed by the one or more processors cause the processor to: display one or more risk categories to a user using the display; prompt the user to input one or more risk levels via the interface, wherein each risk level on the one or more risk levels corresponds to the one or more risk categories displayed; display one or more test objectives or controls via the display; prompt the user to indicate which of the one or more test objectives are to be evaluated via the displaying; and wherein in response to the user providing one or more risk levels and one or more test objectives, the electronic processor is caused to: convert the one or more user provided risk levels and one or more test objectives into one or more test procedures to be implemented by a real-time distributed ledger-based computing system validation tool; and transmit the generated one or more test procedures to an external user.
 12. The computing system of claim 11, wherein the one or more risk categories are selected from a group consisting of government and oversight, cyber security, infrastructure layer, architecture layer, operational layer, and transaction layer.
 13. The computing system of claim 12, wherein if the user selects a transaction layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate an application layer of a distributed ledger-based computing system technology stack.
 14. The computing system of claim 12, wherein if the user selects a blockchain architecture risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a decentralized protocols and encryption layer of a distributed ledger-based computing system technology stack.
 15. The computing system of claim 12, wherein if the user selects an operational layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a permissioned network layer of a distributed ledger-based computing system technology stack.
 16. The computing system of claim 12, wherein if the user selects an infrastructure layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a shared data layer of a distributed ledger-based computing system technology stack.
 17. The computing system of claim 16, wherein if the user selects an infrastructure layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a commercial API layer of a distributed ledger-based computing system technology stack.
 18. The computing system of claim 17, wherein if the user selects an infrastructure layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate overlay network layer of a distributed ledger-based computing system technology stack.
 19. The computing system of claim 11, wherein transmitting the generated one or more test procedures to an external user includes transmitting the generated one or more test procedures to a real-time continuous distributed ledger-based computing system auditing tool.
 20. The computing system of claim 19, wherein transmitting the generated one or more test procedures includes writing the generated one or more test procedures to a planning file, and transmitting the planning file to the real-time continuous distributed ledger-based computing system auditing tool.
 21. A computer readable storage medium storing one or more programs, the one or more programs comprising instructions, which, when executed by an electronic device with a display and a user input interface, cause the device to: display one or more risk categories to a user using the display; prompt the user to input one or more risk levels via the interface, wherein each risk level on the one or more risk levels corresponds to the one or more risk categories displayed; display one or more test objectives or controls via the display; prompt the user to indicate which of the one or more test objectives are to be evaluated via the displaying; and wherein in response to the user providing one or more risk levels and one or more test objectives, the device is caused to: convert the one or more user provided risk levels and one or more test objectives into one or more test procedures to be implemented by a real-time distributed ledger-based computing system validation tool; and transmit the generated one or more test procedures to an external user.
 22. The computer readable storage medium of claim 21, wherein the one or more risk categories are selected from a group consisting of government and oversight, cyber security, infrastructure layer, architecture layer, operational layer, and transaction layer.
 23. The computer readable storage medium of claim 22, wherein if the user selects a transaction layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate an application layer of a distributed ledger-based computing system technology stack.
 24. The computer readable storage medium of claim 22, wherein if the user selects a blockchain architecture risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a decentralized protocols and encryption layer of a distributed ledger-based computing system technology stack.
 25. The computer readable storage medium of claim 22, wherein if the user selects an operational layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a permissioned network layer of a distributed ledger-based computing system technology stack.
 26. The computer readable storage medium of claim 22, wherein if the user selects an infrastructure layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a shared data layer of a distributed ledger-based computing system technology stack.
 27. The c computer readable storage medium of claim 26, wherein if the user selects an infrastructure layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate a commercial API layer of a distributed ledger-based computing system technology stack.
 28. The computer readable storage medium of claim 27, wherein if the user selects an infrastructure layer risk category, the electronic device is caused to convert the one or more user provided risk levels into one or more test procedures configured to validate overlay network layer of a distributed ledger-based computing system technology stack.
 29. The computer readable storage medium of claim 21, wherein transmitting the generated one or more test procedures to an external user includes transmitting the generated one or more test procedures to a real-time continuous distributed ledger-based computing system auditing tool.
 30. The computer readable storage medium of claim 29, wherein transmitting the generated one or more test procedures includes writing the generated one or more test procedures to a planning file, and transmitting the planning file to the real-time continuous distributed ledger-based computing system auditing tool. 